From francesco.fondelli@gmail.com Wed Feb 1 01:24: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 D14ED21F84C4 for ; Wed, 1 Feb 2012 01:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 H9kikYX4Yf72 for ; Wed, 1 Feb 2012 01:24:58 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3E21F85AD for ; Wed, 1 Feb 2012 01:24:57 -0800 (PST) Received: by yhkk25 with SMTP id k25so523730yhk.31 for ; Wed, 01 Feb 2012 01:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=BTO3LZ6pLSgFblCFx/g+XcuUX3KGF0Lto1cJokmMmVM=; b=V3xxdygFG3NRlMPIbr1fF+hnpmTo0zsgMlNlv+hV4lbaT3Te+HcbQexNvCCifxVJGv T0dMu+b0WLnDJssxBOZ2vfU9oNgMqFWXBFV+iqZe6NT1TyUMBeQkZ3WWsm49kFzJXuWG 7V1KNbPMuuVSyg/QCeU3pD74avOkjG1FNeFKw= MIME-Version: 1.0 Received: by 10.236.175.164 with SMTP id z24mr27288271yhl.84.1328088297504; Wed, 01 Feb 2012 01:24:57 -0800 (PST) Received: by 10.236.183.169 with HTTP; Wed, 1 Feb 2012 01:24:57 -0800 (PST) Date: Wed, 1 Feb 2012 10:24:57 +0100 Message-ID: From: Francesco Fondelli To: mpls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [mpls] questions about draft-ietf-mpls-tp-te-mib-01 and RFC 6370 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, 01 Feb 2012 09:24:58 -0000 Hi all, 1) --- quote from RFC 6370, Section 5.1 At each end point, a tunnel is uniquely identified by the end point's Node_ID and a locally assigned tunnel number. Specifically, a "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique within the context of the Node_ID. --- RFC says "At each end point"... what about transit nodes? In a classic MPLS-TE management plane (3812 + 3813) context a tunnel is identified by {mplsTunnelIngressLSRId, mplsTunnelEgressLSRId, mplsTunnelIndex}. This 3-tuple is the same on head (ingress), tail (egress) and transit nodes. May I assume that the Tunnel_ID definition (i.e. A1-{Node_ID::Tunnel_Num}:: Z9-{Node_ID::Tunnel_Num}) is applicable/valid also for the identification of a tunnel at a transit node ? Was this the intention of RFC 6370 authors ? 2) In case the Tunnel_ID as described in RFC 6370 section 5.1 is OK for identification of tunnels at transit routers then I'd like to understand how to accommodate these bits A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num} or at the LSP_ID granularity these bits A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num into a single mplsTunnelTable/mplsTunnelExtTable entry in case i) mplsTunnelRole == transit and ii) the LSP is co-routed bidirectional. This question is primarily intended for draft-ietf-mpls-tp-te-mib-01 authors. An example would be of great help. thanks a lot ciao FF From aldrin.ietf@gmail.com Fri Feb 3 14:53: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 0335221F85C6 for ; Fri, 3 Feb 2012 14:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 ayrCrOM5mxQi for ; Fri, 3 Feb 2012 14:52:59 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3139E21F858F for ; Fri, 3 Feb 2012 14:52:59 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so209709pbc.31 for ; Fri, 03 Feb 2012 14:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=VH6noVUVzwnuzL82678Wb6kOjm2c4wwEucZPokDfGtU=; b=mmNj0mHbrtxBXoC7bfMUzqkwqJHdRzGP8ugydzombta71hPEKyHRKJpJ8MgxSQ1nJJ SEJe6tZkddTIHSD6Eu3YRofEnizVWojGM9ZL/PNUlauZtdlyYGiUoeMnd45mErC0nr+M iaGQE8uM+SNlc3V+jXice2D53Mr9fEsB2xbR4= Received: by 10.68.189.196 with SMTP id gk4mr21099961pbc.44.1328309578976; Fri, 03 Feb 2012 14:52:58 -0800 (PST) Received: from [192.168.1.5] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id a5sm16141921pbh.15.2012.02.03.14.52.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 14:52:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_630531C5-CA84-4D87-94F0-667B6C19C360" From: Sam Aldrin In-Reply-To: Date: Fri, 3 Feb 2012 14:52:49 -0800 Message-Id: References: To: Francesco Fondelli X-Mailer: Apple Mail (2.1257) Cc: mpls@ietf.org, Davide Chiara , draft-ietf-mpls-tp-te-mib@tools.ietf.org, Francesco Fondelli Subject: Re: [mpls] questions about draft-ietf-mpls-tp-te-mib-01 and RFC 6370 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, 03 Feb 2012 22:53:00 -0000 --Apple-Mail=_630531C5-CA84-4D87-94F0-667B6C19C360 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Francesco, Please find answers, inline, to your questions. Cheers -sam On Feb 1, 2012, at 1:24 AM, Francesco Fondelli wrote: > Hi all, >=20 > 1) >=20 > --- quote from RFC 6370, Section 5.1 >=20 > At each end point, a tunnel is uniquely identified by the end point's > Node_ID and a locally assigned tunnel number. Specifically, a > "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique > within the context of the Node_ID. >=20 > --- >=20 > RFC says "At each end point"... what about transit nodes? In a > classic MPLS-TE management plane (3812 + 3813) context a tunnel is > identified by {mplsTunnelIngressLSRId, mplsTunnelEgressLSRId, > mplsTunnelIndex}. This 3-tuple is the same on head (ingress), > tail (egress) and transit nodes. >=20 > May I assume that the Tunnel_ID definition (i.e. = A1-{Node_ID::Tunnel_Num}:: > Z9-{Node_ID::Tunnel_Num}) is applicable/valid also for the = identification > of a tunnel at a transit node ? Was this the intention of RFC 6370 > authors ? Yes, that is our understanding as well. >=20 > 2) >=20 > In case the Tunnel_ID as described in RFC 6370 section 5.1 is OK for > identification of tunnels at transit routers then I'd like to = understand > how to accommodate these bits >=20 > A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num} >=20 > or at the LSP_ID granularity these bits >=20 > A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num >=20 > into a single mplsTunnelTable/mplsTunnelExtTable entry in case i) > mplsTunnelRole =3D=3D transit and ii) the LSP is co-routed = bidirectional. >=20 > This question is primarily intended for draft-ietf-mpls-tp-te-mib-01 > authors. An example would be of great help. Short answer is, the example in the MIB doesn't describe completely the = case of co-routed bi-directional tunnels. Long answer is, we know the problem and wanting to publish a newer = version with all the necessary info and examples. But we are waiting for = WG chairs to make a call on the read-write objects within the MIB, so = that all the necessary changes could be taken care off in the new = version. Having said that, the this is what we planned to change in = order to support co-routed and associated tunnels. Co-routed bi-directional tunnels:=20 ------------------------------------------- This will be modeled similar to GMPLS mib. i.e. there will be one = instance of tunnel table and two separate instances of XC table, one per = each direction. The row pointer object in the XC table will point to the = tunnel instance. In this case, both XC table instances will point to the = same Tunnel instance. Tunnel table: Entry1=3D>1[id],1[instance],10[ingress],20[egress] | | Row Pointer v XCTable(1[xcIndex].1[inIndex].1[outIndex]) XC Table: Entry1=3D>1.1.1 - Forward direction Entry2=3D>1.2.2 - Reverse direction Associated bi-directional tunnels:=20 -------------------------------------------- This is similar to the example laid out in the existing version of the = MIB. There will be one instance of tunnel table and XC table per = direction. There will be a new row pointer object within XC table which = will point to the row instance of the reverse/opposite direction. In the = case of co-routed tunnels, this object could be NULL or point to self. Tunnel table (Forward direction) Entry1=3D>1[id],1[instance],10[ingress],20[egress] | | Row Pointer v XCTable(1[xcIndex].1[inIndex].1[outIndex]) =20 XC Table: Entry1=3D>1.1.1 - Forward direction Tunnel table (Reverse direction) Entry2=3D>2[id],1[instance],20[ingress],10[egress] | | Row Pointer v XCTable(1[xcIndex].1[inIndex].1[outIndex]) =20 XC Table: Entry2=3D>2.1.1 - Reverse direction This should be clearly identified with an example in the new version of = the MIB. HTH, -sam >=20 >=20 >=20 > thanks a lot > ciao > FF > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_630531C5-CA84-4D87-94F0-667B6C19C360 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = all,

1)

--- quote from RFC 6370, Section 5.1

=  At each end point, a tunnel is uniquely identified by the end = point's
 Node_ID and a locally assigned tunnel number. =  Specifically, a
 "Tunnel Number" (Tunnel_Num) is a 16-bit = unsigned integer unique
 within the context of the = Node_ID.

---

 RFC says "At each end point"... what = about transit nodes?  In a
classic MPLS-TE management plane = (3812 + 3813) context a tunnel is
identified by = {mplsTunnelIngressLSRId, mplsTunnelEgressLSRId,
mplsTunnelIndex}. =  This 3-tuple is the same on head (ingress),
tail (egress) and = transit nodes.

 May I assume that the Tunnel_ID definition = (i.e. A1-{Node_ID::Tunnel_Num}::
Z9-{Node_ID::Tunnel_Num}) is = applicable/valid also for the identification
of a tunnel at a transit = node ?  Was this the intention of RFC 6370
authors = ?
Yes, that is our understanding as = well.

2)

 In case the = Tunnel_ID as described in RFC 6370 section 5.1 is OK = for
identification of tunnels at transit routers then I'd like to = understand
how to accommodate these = bits

A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}

or = at the LSP_ID granularity these = bits

A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
into a single mplsTunnelTable/mplsTunnelExtTable entry in case = i)
mplsTunnelRole =3D=3D transit and ii) the LSP is co-routed = bidirectional.

 This question is primarily intended for = draft-ietf-mpls-tp-te-mib-01
authors.  An example would be of = great help.
Short answer is, the example in = the MIB doesn't describe completely the case of co-routed bi-directional = tunnels.

Long answer is, we know the problem = and wanting to publish a newer version with all the necessary info and = examples. But we are waiting for WG chairs to make a call on the = read-write objects within the MIB, so that all the necessary changes = could be taken care off in the new version. Having said that, the this = is what we planned to change in order to support co-routed and = associated tunnels.

Co-routed bi-directional = tunnels: 
-------------------------------------------
=
This will be modeled similar to GMPLS mib. i.e. there will be one = instance of tunnel table and two separate instances of XC table, one per = each direction. The row pointer object in the XC table will point to the = tunnel instance. In this case, both XC table instances will point to the = same Tunnel instance.

Tunnel = table:
Entry1=3D>1[id],1[instance],10[ingress],20[egress]
                  =      |
          =              | Row = Pointer
              =         =  v
XCTable(1[xcIndex].1[inIndex].1[outIndex])
XC Table:
Entry1=3D>1.1.1 - Forward = direction
Entry2=3D>1.2.2 - Reverse = direction


Associated = bi-directional = tunnels: 
--------------------------------------------
This is similar to the example laid out in the existing version of = the MIB. There will be one instance of tunnel table and XC table per = direction. There will be a new row pointer object within XC table = which will point to the row instance of the reverse/opposite direction. = In the case of co-routed tunnels, this object could be NULL or point to = self.

Tunnel table (Forward = direction)
Entry1=3D>1[id],1[instance],10[ingress],20[egress]=
                =        |
        =                | Row = Pointer
              =         =  v
XCTable(1[xcIndex].1[inIndex].1[outIndex])
&nb= sp;
XC Table:
Entry1=3D>1.1.1 - Forward = direction

Tunnel table (Reverse = direction)
Entry2=3D>2[id],1[instance],20[ingress],10[egress]=
                =        |
        =                | Row = Pointer
              =         =  v
XCTable(1[xcIndex].1[inIndex].1[outIndex])
&nb= sp;
XC Table:
Entry2=3D>2.1.1 - Reverse = direction

This should be clearly = identified with an example in the new version of the = MIB.

HTH,
-sam



thanks a = lot
ciao
FF
_______________________________________________
mp= ls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

= --Apple-Mail=_630531C5-CA84-4D87-94F0-667B6C19C360-- From mustapha.aissaoui@alcatel-lucent.com Fri Feb 3 15:12: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 7AF3D21F8533 for ; Fri, 3 Feb 2012 15:12:28 -0800 (PST) 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 Lwhowe8gdeIz for ; Fri, 3 Feb 2012 15:12:27 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF9721F8530 for ; Fri, 3 Feb 2012 15:12:27 -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 q13NCH5R026922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Feb 2012 17:12:18 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q13NCGak007705 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 3 Feb 2012 17:12:17 -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, 3 Feb 2012 17:12:16 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: "mpls@ietf.org" Date: Fri, 3 Feb 2012 17:12:15 -0600 Thread-Topic: Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AcziyUTVUtTomjEtROapf+FH1ToxHw== Message-ID: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Subject: [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, 03 Feb 2012 23:12:28 -0000 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 so= me of these comments were already raised on this mailing list. =20 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 loo= pback 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 r= efer 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 eg= ress router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches wit= h that of the LDP hello adjacency on the next-hop interface. "=20 MA> RFC 5036 makes no tie, and there should not be, between the type of res= olved FEC and the adjacency to the next-hop. I think this statement should = be removed.=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 anythin= g to do with the address family. It only requires that an LSR advertises th= e same transport address in all Hello adjacencies that advertise the same l= abel 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 establish= ing the TCP connection.=20 In practice though, most implementations allow Hello adjacencies over paral= lel 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 sa= me 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 pe= er (LSR-id, label-space} over a given interface, whichever came up first. O= ver 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 R= FC 5036 implementations if an LSR receives two optional IPv4 transport addr= ess TLVs. RFC 506 does not say what to do with this and was left for implem= entations to handle. If we absolutely need to specify something, maybe we s= hould say only the first TLV in the Hello message is processed. =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 mai= ntained to each peer over a dual-stack interface. =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.=20 The proper solution to this is to add an IPV6 LDP capability to negotiate w= hich 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 I= Pv4-only LDP implementations), this document specifies that=20 - 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.=20 2. An LSR MUST NOT send an Address message (or Address Withdraw message) wi= th an Address List TLV containing IP addresses of different address-family.= In other words, an Address List TLV in the Address (or Address Withdraw) m= essage MUST contain the addresses belonging to the same address-family.. " MA> This is yet another narrow interpretation of RFC 5036. There is no just= ification 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 h= as its own Type, Length, Value and is self sufficient. Although implementat= ions don't mix and match FEC elements but they are designed to handle it. S= ame applies to Address list TLV.=20 =20 9. Section 8 - LDP Identifiers and Next Hop Addresses MA> I believe the need to handle duplicate interface addresses received fro= m two different peers is not a new issue. It needed to be handled in existi= ng IPv4 based LDP implementations. Maybe the authors can specify why duplic= ate link local addresses is any different. =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 defin= ing 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= From shane@castlepoint.net Fri Feb 3 20:32: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 BA37321F84F7 for ; Fri, 3 Feb 2012 20:32:29 -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 E8MmW1ikM7+f for ; Fri, 3 Feb 2012 20:32:28 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8D05321F84F6 for ; Fri, 3 Feb 2012 20:32:28 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 23BEE268063; Fri, 3 Feb 2012 21:32:28 -0700 (MST) Received: from mbpw.castlepoint.net (63-225-243-189.hlrn.qwest.net [63.225.243.189]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 03 Feb 2012 21:32:27 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=63.225.243.189; client-port=53894; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Date: Fri, 3 Feb 2012 21:32:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> To: "Aissaoui, Mustapha (Mustapha)" X-Mailer: Apple Mail (2.1251.1) 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, 04 Feb 2012 04:32:29 -0000 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. >=20 > 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 >=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 > 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. > "=20 > 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 >=20 >=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. 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.=20 >=20 > 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 >=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 >=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 >=20 >=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. >=20 > 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 >=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.=20 > 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 >=20 > 8. Section 7 - Label Distribution; Fourth paragraph: > " > Additionally, to ensure backward compatibility (and interoperability = with IPv4-only LDP implementations), this document specifies that=20 > - 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.=20 > 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 >=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 >=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 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 From francesco.fondelli@gmail.com Mon Feb 6 02:41: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 5E2D821F85F0 for ; Mon, 6 Feb 2012 02:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 kPi5cqCYufUX for ; Mon, 6 Feb 2012 02:41:46 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC121F85E9 for ; Mon, 6 Feb 2012 02:41:46 -0800 (PST) Received: by yhkk25 with SMTP id k25so2704048yhk.31 for ; Mon, 06 Feb 2012 02:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rAKKIcEJxezEtskOI7Hs7Oij97ffL941WNgEQv3r1KQ=; b=a+tBInabh9aiRGC0r4EVID9tPXc2BZUHpmsDlfRQiJuZq5Xjguu3/n7aGogbMB80kV 2sKFj+EjyuKa/gYHorFj1N/DAFmpowLlVN970Y4agg3sZqV0dEtzIEPZUwTVt+m27M38 JAOigpCPzteJHsLWw4J63Cp4Y6NTMP6hxuMM8= MIME-Version: 1.0 Received: by 10.236.9.106 with SMTP id 70mr22947131yhs.118.1328524906092; Mon, 06 Feb 2012 02:41:46 -0800 (PST) Received: by 10.236.155.103 with HTTP; Mon, 6 Feb 2012 02:41:46 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Feb 2012 11:41:46 +0100 Message-ID: From: Francesco Fondelli To: Sam Aldrin Content-Type: text/plain; charset=UTF-8 Cc: mpls@ietf.org, Davide Chiara , draft-ietf-mpls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] questions about draft-ietf-mpls-tp-te-mib-01 and RFC 6370 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, 06 Feb 2012 10:41:47 -0000 Hi Sam, all, very clear, thank you very much. So... given the example Sam provided and the Section 5.3 of RFC 6370 may I assume that in case of bidi co-routed A1-Tunnel_Num is (must? MUST? should? SHOULD? be) equal to Z9-Tunnel_Num ? thank you ciao FF On Fri, Feb 3, 2012 at 11:52 PM, Sam Aldrin wrote: > Francesco, > > Please find answers, inline, ?to your questions. > > Cheers > -sam > > On Feb 1, 2012, at 1:24 AM, Francesco Fondelli wrote: > > Hi all, > > 1) > > --- quote from RFC 6370, Section 5.1 > > ?At each end point, a tunnel is uniquely identified by the end point's > ?Node_ID and a locally assigned tunnel number. ?Specifically, a > ?"Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique > ?within the context of the Node_ID. > > --- > > ?RFC says "At each end point"... what about transit nodes? ?In a > classic MPLS-TE management plane (3812 + 3813) context a tunnel is > identified by {mplsTunnelIngressLSRId, mplsTunnelEgressLSRId, > mplsTunnelIndex}. ?This 3-tuple is the same on head (ingress), > tail (egress) and transit nodes. > > ?May I assume that the Tunnel_ID definition (i.e. A1-{Node_ID::Tunnel_Num}:: > Z9-{Node_ID::Tunnel_Num}) is applicable/valid also for the identification > of a tunnel at a transit node ? ?Was this the intention of RFC 6370 > authors ? > > Yes, that is our understanding as well. > > > 2) > > ?In case the Tunnel_ID as described in RFC 6370 section 5.1 is OK for > identification of tunnels at transit routers then I'd like to understand > how to accommodate these bits > > A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num} > > or at the LSP_ID granularity these bits > > A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num > > into a single mplsTunnelTable/mplsTunnelExtTable entry in case i) > mplsTunnelRole == transit and ii) the LSP is co-routed bidirectional. > > ?This question is primarily intended for draft-ietf-mpls-tp-te-mib-01 > authors. ?An example would be of great help. > > Short answer is, the example in the MIB doesn't describe completely the case > of co-routed bi-directional tunnels. > > Long answer is, we know the problem and wanting to publish a newer version > with all the necessary info and examples. But we are waiting for WG chairs > to make a call on the read-write objects within the MIB, so that all the > necessary changes could be taken care off in the new version. Having said > that, the this is what we planned to change in order to support co-routed > and associated tunnels. > > Co-routed bi-directional tunnels:? > ------------------------------------------- > This will be modeled similar to GMPLS mib. i.e. there will be one instance > of tunnel table and two separate instances of XC table, one per each > direction. The row pointer object in the XC table will point to the tunnel > instance. In this case, both XC table instances will point to the same > Tunnel instance. > > Tunnel table: > Entry1=>1[id],1[instance],10[ingress],20[egress] > ? ? ? ? ? ? ? ? ? ? ? ?| > ? ? ? ? ? ? ? ? ? ? ? ?| Row Pointer > ? ? ? ? ? ? ? ? ? ? ? ?v > XCTable(1[xcIndex].1[inIndex].1[outIndex]) > > XC Table: > Entry1=>1.1.1 - Forward direction > Entry2=>1.2.2 - Reverse direction > > > Associated bi-directional tunnels:? > -------------------------------------------- > This is similar to the example laid out in the existing version of the MIB. > There will be one instance of tunnel table and XC table per direction. There > will be a new row pointer object within XC table which will point to the row > instance of the reverse/opposite direction. In the case of co-routed > tunnels, this object could be NULL or point to self. > > Tunnel table (Forward direction) > Entry1=>1[id],1[instance],10[ingress],20[egress] > ? ? ? ? ? ? ? ? ? ? ? ?| > ? ? ? ? ? ? ? ? ? ? ? ?| Row Pointer > ? ? ? ? ? ? ? ? ? ? ? ?v > XCTable(1[xcIndex].1[inIndex].1[outIndex]) > ? > XC Table: > Entry1=>1.1.1 - Forward direction > > Tunnel table (Reverse direction) > Entry2=>2[id],1[instance],20[ingress],10[egress] > ? ? ? ? ? ? ? ? ? ? ? ?| > ? ? ? ? ? ? ? ? ? ? ? ?| Row Pointer > ? ? ? ? ? ? ? ? ? ? ? ?v > XCTable(1[xcIndex].1[inIndex].1[outIndex]) > ? > XC Table: > Entry2=>2.1.1 - Reverse direction > > This should be clearly identified with an example in the new version of the > MIB. > > HTH, > -sam > > > > > thanks a lot > ciao > FF > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From bedard.phil@gmail.com Mon Feb 6 07:59:32 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 2F62C21F85FD for ; Mon, 6 Feb 2012 07:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 6wM-9iVOnTLF for ; Mon, 6 Feb 2012 07:59:28 -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 269D021F85DB for ; Mon, 6 Feb 2012 07:59:28 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8486651obb.31 for ; Mon, 06 Feb 2012 07:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=OLBNqFTmiPzd3+CKy1L5lc64MVCYZPNUgMClgc7F4PE=; b=hLajwxeKDdEu/XOK0uK8FIO8V9FrtbYWujUXpC78MMRoYPg827lHebjSwqc/01Ftut 2A+HMwbBCGQWe3269gfKEPAZpwpZqqVom7avcOW5kzOl+7jZaePmPqkuXUmDsCrXrA81 KVAYPLAsxUydHADWeEQjaM8806kKfUc1A0gxQ= Received: by 10.182.74.102 with SMTP id s6mr17175611obv.46.1328543967805; Mon, 06 Feb 2012 07:59:27 -0800 (PST) Received: from [10.63.99.102] (gw1.cox.com. [24.248.74.254]) by mx.google.com with ESMTPS id s2sm11112669obx.1.2012.02.06.07.59.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Feb 2012 07:59:26 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 06 Feb 2012 10:59:16 -0500 From: Phil Bedard To: Shane Amante , "Aissaoui, Mustapha (Mustapha)" Message-ID: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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, 06 Feb 2012 15:59:32 -0000 As an operator I second this opinion. Providers using IS-IS as a V4/V6 IGP generally separate those processes and maintain different adjacencies even though IS-IS is capable of both. Phil On 2/3/12 11:32 PM, "Shane Amante" wrote: >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. >> >>========================================================================= >>============== >> >> 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. >> >> >>========================================================================= >>============== >> _______________________________________________ >> 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 mustapha.aissaoui@alcatel-lucent.com Mon Feb 6 12:21: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 90AB821F8759 for ; Mon, 6 Feb 2012 12:21:46 -0800 (PST) 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 pHJalT1hWcEq for ; Mon, 6 Feb 2012 12:21:45 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 478F421F8758 for ; Mon, 6 Feb 2012 12:21:45 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q16KLUmd001049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Feb 2012 14:21:30 -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 q16KLTrW015624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Feb 2012 14:21:30 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 6 Feb 2012 14:21:29 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: Shane Amante Date: Mon, 6 Feb 2012 14:21:29 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Aczi9gKBKcjtZosmRQi3iyzlmOQNUwB6XhAA Message-ID: <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@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: 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 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: Mon, 06 Feb 2012 20:21:46 -0000 Hi Shane, LDP as defined in RFC 5036 can carry multiple FEC types within an LDP sessi= on from a peer which is identified by the LDP identifier tuple {LSR-id, lab= el-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 virtualizati= on of LDP, then a different LDP identifier altogether can be used to establ= ish a separate LDP session. Other than that, there is no relation between t= he type of adjacency and the FEC which are carried. For example, the same L= DP Hello Adjacency and LDP session are used to carry unicast FECs, multicas= t 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 spa= ce. This way, we can have separate Hello adjacency and LDP session and it i= s 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 a= djacency.=20 By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate Hello ad= jacency but a single shared LDP session. It is not exactly what you are ask= ing for. Regards, Mustapha. -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net]=20 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 comm= ents -- actually, moreso from #3 -- that you are opposed to maintaining sep= arate 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: on= e 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 exch= ange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one more conc= rete example, 6man/v6ops are only right now working on improving the robust= ness of IPv6 ND to DoS attacks. There are potentially other areas where IPv= 6 will be hardened, as well. The bottom-line is I do not want problems in v= 6 to affect exchange of FEC's + labels for v4, or vice-versa. Also, FWIW, t= here has already been a precedent here wrt BGP where there it maintains sep= arate neighbors/sessions for each address family, so why aren't we doing th= e same thing for LDP? Ultimately, having separate sessions over-the-wire is much more intuitive t= o operators in lots of cases where they may expect that a configuration cha= nge or bugs they /think/ are only going to affect one address family, reall= y do only affect one address family. Besides, LDP Hello & Sessions timers, = when set to default, are extremely relaxed (order of several seconds), so t= he burden on implementations to maintain separate sessions should be minisc= ule. 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 de= vice 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 cal= l 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 > 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 >=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 l= oopback interface of the egress router, not any other interface. That is wh= y RFC 5036 explicitly states /32 for IPv4. In my view, we should explicitly= refer to /128 for IPv6. >=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 w= ith that of the LDP hello adjacency on the next-hop interface. > "=20 > MA> RFC 5036 makes no tie, and there should not be, between the type of r= esolved FEC and the adjacency to the next-hop. I think this statement shoul= d be removed.=20 >=20 >=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 anyth= ing 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 tha= t same paragraph was to make sure that if two LSRs are establishing multipl= e Hello adjacencies that they play the same active/passive role for establi= shing the TCP connection.=20 >=20 > In practice though, most implementations allow Hello adjacencies over par= allel 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 i= t in this draft. >=20 >=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 separa= te Hello ajacencies per peer. In practice, each router can send both IPv4 a= nd 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 th= ey want to form which means there is only a need to send one type of hello. >=20 >=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 ad= dress TLVs. RFC 506 does not say what to do with this and was left for impl= ementations to handle. If we absolutely need to specify something, maybe we= should say only the first TLV in the Hello message is processed. =20 >=20 >=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. >=20 > 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 m= aintained to each peer over a dual-stack interface. >=20 >=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 shou= ld depend on the existence of an IPv6 Hello adjacency. This is a very narro= w interpretation of RFC 5036.=20 > 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 adjacenc= y is IPv4 or IPv6. This is already done for multicast LDP (mLDP) FECs. >=20 >=20 > 8. Section 7 - Label Distribution; Fourth paragraph: > " > Additionally, to ensure backward compatibility (and interoperability=20 > with IPv4-only LDP implementations), this document specifies that > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV containi= ng FEC Elements of different address-family. In other words, a FEC TLV in t= he label mapping message MUST contain the FEC Elements belonging to the sam= e address-family.=20 > 2. An LSR MUST NOT send an Address message (or Address Withdraw message) = with an Address List TLV containing IP addresses of different address-famil= y. 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 ju= stification 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 implement= ations don't mix and match FEC elements but they are designed to handle it.= Same applies to Address list TLV.=20 >=20 >=20 > 9. Section 8 - LDP Identifiers and Next Hop Addresses > MA> I believe the need to handle duplicate interface addresses received f= rom two different peers is not a new issue. It needed to be handled in exis= ting IPv4 based LDP implementations. Maybe the authors can specify why dupl= icate link local addresses is any different. >=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 def= ining a new protocol and as such it should remain optional as in RFC 5036. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 From pranjal.dutta@alcatel-lucent.com Mon Feb 6 12:30: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 5D79721F8792 for ; Mon, 6 Feb 2012 12:30:30 -0800 (PST) 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 Kz8OIYqdSzUy for ; Mon, 6 Feb 2012 12:30:29 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1583921F878A for ; Mon, 6 Feb 2012 12:30:28 -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 q16KUCbK003812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Feb 2012 14:30:15 -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 q16KUBHN001398 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Feb 2012 02:00: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; Tue, 7 Feb 2012 02:00:11 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Aissaoui, Mustapha (Mustapha)" , Shane Amante Date: Tue, 7 Feb 2012 02:00:08 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Aczi9gKBKcjtZosmRQi3iyzlmOQNUwB6XhAAAAtwP+A= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@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.33 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, 06 Feb 2012 20:30:30 -0000 I second to Mustapha. Further, we had already started LDP capabilities base= d approach on various FEC types support over a single LDP session (e.g=20 mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a so= und approach and would raise other questions such as which adjacency to be= =20 used for various mLdp fec types etc (as some of those has mix of ipv4 + ipv= 6) etc. Thanks, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ais= saoui, Mustapha (Mustapha) Sent: Monday, February 06, 2012 12: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 sessi= on from a peer which is identified by the LDP identifier tuple {LSR-id, lab= el-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 virtualizati= on of LDP, then a different LDP identifier altogether can be used to establ= ish a separate LDP session. Other than that, there is no relation between t= he type of adjacency and the FEC which are carried. For example, the same L= DP Hello Adjacency and LDP session are used to carry unicast FECs, multicas= t 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 spa= ce. This way, we can have separate Hello adjacency and LDP session and it i= s 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 a= djacency.=20 By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate Hello ad= jacency but a single shared LDP session. It is not exactly what you are ask= ing for. Regards, Mustapha. -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net]=20 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 comm= ents -- actually, moreso from #3 -- that you are opposed to maintaining sep= arate 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: on= e 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 exch= ange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one more conc= rete example, 6man/v6ops are only right now working on improving the robust= ness of IPv6 ND to DoS attacks. There are potentially other areas where IPv= 6 will be hardened, as well. The bottom-line is I do not want problems in v= 6 to affect exchange of FEC's + labels for v4, or vice-versa. Also, FWIW, t= here has already been a precedent here wrt BGP where there it maintains sep= arate neighbors/sessions for each address family, so why aren't we doing th= e same thing for LDP? Ultimately, having separate sessions over-the-wire is much more intuitive t= o operators in lots of cases where they may expect that a configuration cha= nge or bugs they /think/ are only going to affect one address family, reall= y do only affect one address family. Besides, LDP Hello & Sessions timers, = when set to default, are extremely relaxed (order of several seconds), so t= he burden on implementations to maintain separate sessions should be minisc= ule. 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 de= vice 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 cal= l 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 > 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 >=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 l= oopback interface of the egress router, not any other interface. That is wh= y RFC 5036 explicitly states /32 for IPv4. In my view, we should explicitly= refer to /128 for IPv6. >=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 w= ith that of the LDP hello adjacency on the next-hop interface. > "=20 > MA> RFC 5036 makes no tie, and there should not be, between the type of r= esolved FEC and the adjacency to the next-hop. I think this statement shoul= d be removed.=20 >=20 >=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 anyth= ing 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 tha= t same paragraph was to make sure that if two LSRs are establishing multipl= e Hello adjacencies that they play the same active/passive role for establi= shing the TCP connection.=20 >=20 > In practice though, most implementations allow Hello adjacencies over par= allel 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 i= t in this draft. >=20 >=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 separa= te Hello ajacencies per peer. In practice, each router can send both IPv4 a= nd 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 th= ey want to form which means there is only a need to send one type of hello. >=20 >=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 ad= dress TLVs. RFC 506 does not say what to do with this and was left for impl= ementations to handle. If we absolutely need to specify something, maybe we= should say only the first TLV in the Hello message is processed. =20 >=20 >=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. >=20 > 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 m= aintained to each peer over a dual-stack interface. >=20 >=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 shou= ld depend on the existence of an IPv6 Hello adjacency. This is a very narro= w interpretation of RFC 5036.=20 > 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 adjacenc= y is IPv4 or IPv6. This is already done for multicast LDP (mLDP) FECs. >=20 >=20 > 8. Section 7 - Label Distribution; Fourth paragraph: > " > Additionally, to ensure backward compatibility (and interoperability=20 > with IPv4-only LDP implementations), this document specifies that > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV containi= ng FEC Elements of different address-family. In other words, a FEC TLV in t= he label mapping message MUST contain the FEC Elements belonging to the sam= e address-family.=20 > 2. An LSR MUST NOT send an Address message (or Address Withdraw message) = with an Address List TLV containing IP addresses of different address-famil= y. 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 ju= stification 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 implement= ations don't mix and match FEC elements but they are designed to handle it.= Same applies to Address list TLV.=20 >=20 >=20 > 9. Section 8 - LDP Identifiers and Next Hop Addresses > MA> I believe the need to handle duplicate interface addresses received f= rom two different peers is not a new issue. It needed to be handled in exis= ting IPv4 based LDP implementations. Maybe the authors can specify why dupl= icate link local addresses is any different. >=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 def= ining a new protocol and as such it should remain optional as in RFC 5036. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 bedard.phil@gmail.com Mon Feb 6 12:45: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 622DE21F879B for ; Mon, 6 Feb 2012 12:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 MX0RQ6FcVEnJ for ; Mon, 6 Feb 2012 12:45:07 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D27521F879A for ; Mon, 6 Feb 2012 12:45:07 -0800 (PST) Received: by iagf6 with SMTP id f6so10794841iag.31 for ; Mon, 06 Feb 2012 12:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=0WPnEhP+3UhPYpaUAmpRY9ps2dnSD+spqk+Lb+0ZoTA=; b=oE/DTmw0nKChF78AAx7xAh5JygGHdC5WFvMU6cbULcADTet9v7HWke8SgewC8HlfB+ RW5dsPSkYWRw7Ao9/NFHRMvXhk73sePSxXg5lbSMVBbFJNm7ay1uxwRiFfZWVnMOGd+4 TPMSPtIHVA9jonMtaULjld5AEfvYtxKYy4r/k= Received: by 10.42.158.195 with SMTP id i3mr18931584icx.7.1328561106729; Mon, 06 Feb 2012 12:45:06 -0800 (PST) Received: from [192.168.5.208] (nmd.sbx08207.roswega.wayport.net. [98.98.95.198]) by mx.google.com with ESMTPS id ut1sm21157916igc.2.2012.02.06.12.45.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Feb 2012 12:45:05 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 06 Feb 2012 15:44:58 -0500 From: Phil Bedard To: "Dutta, Pranjal K (Pranjal)" , "Aissaoui, Mustapha (Mustapha)" , Shane Amante Message-ID: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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, 06 Feb 2012 20:45:08 -0000 I understand the road LDP has gone down with regards to using a single session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" wrote: >I second to Mustapha. Further, we had already started LDP capabilities >based approach on various FEC types support over a single LDP session >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a >sound approach and would raise other questions such as which adjacency to >be >used for various mLdp fec types etc (as some of those has mix of ipv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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. >> ====================================================================== >> ================= >> >> 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. >> >> ====================================================================== >> ================= _______________________________________________ >> 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 vishwas.ietf@gmail.com Mon Feb 6 13:12: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 6EDBF21F853D for ; Mon, 6 Feb 2012 13:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.063, 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 mCbWFdAbo3aN for ; Mon, 6 Feb 2012 13:12:21 -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 9A13521F8749 for ; Mon, 6 Feb 2012 13:12:08 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8882169obb.31 for ; Mon, 06 Feb 2012 13:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AbQSPyFpUgrj1np/YMJSoeo3GGBOsqcJiTv9eUczv7Y=; b=LFNyynCYJNFFOiurHKhpHIXbI3tCaHT1389pfI2k6jJ9RXcIuCkAOlOxgpFFKgYdED UZHqu0AXL4eRHtlke1ghG7dRkfcXBT6Pc/elocxlcZXPUcLWNAnKNyG1+W2CaY/lJdR+ uJvppB1HlzlWnZyMmLYmoae3/GZwaFOIK605o= MIME-Version: 1.0 Received: by 10.182.86.202 with SMTP id r10mr18206231obz.64.1328562728262; Mon, 06 Feb 2012 13:12:08 -0800 (PST) Received: by 10.182.28.196 with HTTP; Mon, 6 Feb 2012 13:12:08 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Feb 2012 13:12:08 -0800 Message-ID: From: Vishwas Manral To: Phil Bedard Content-Type: multipart/alternative; boundary=f46d0444eadf7adc8604b8521d66 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, 06 Feb 2012 21:12:23 -0000 --f46d0444eadf7adc8604b8521d66 Content-Type: text/plain; charset=ISO-8859-1 Hi Phil, You are right. If we want minimal fate-sharing, we could be using different instances of LDP itself or something in between, in which case we can use different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we can currently support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard wrote: > I understand the road LDP has gone down with regards to using a single > session/adjacency to advertise multiple families of FECs, similar to BGP. > Like I said, many providers these days have taken steps to separate their > IPv6 and IPv4 control planes, usually for shared-fate concerns with > software defects and to just keep things simpler for operational folks to > deal with (which is somewhat debatable). > > Mustapha mentioned BGP but the fact is providers today use two different > sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for > either to advertise both NLRI. > > > Phil > > On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" > wrote: > > >I second to Mustapha. Further, we had already started LDP capabilities > >based approach on various FEC types support over a single LDP session > >(e.g > >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a > >sound approach and would raise other questions such as which adjacency to > >be > >used for various mLdp fec types etc (as some of those has mix of ipv4 + > >ipv6) etc. > > > >Thanks, > >Pranjal > > > >-----Original Message----- > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > >Aissaoui, Mustapha (Mustapha) > >Sent: Monday, February 06, 2012 12: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. > >> ====================================================================== > >> ================= > >> > >> 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. > >> > >> ====================================================================== > >> ================= _______________________________________________ > >> 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 > --f46d0444eadf7adc8604b8521d66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Phil,

You are right. If we want minimal fate-sharing, we could be= using different instances of LDP itself or something in between, in which = case we can use different LSR id/ MT extension etc.

The draft talks = about the case based on current RFC5036, where we can currently support mul= tiple hello adjacencies and a single LDP session.

The draft also in section 7, mentions the use of LDP capability.
Thanks,
Vishwas

On Mon, Feb 6, 2012 a= t 12:44 PM, Phil Bedard <bedard.phil@gmail.com> wrote:
I understand the road LDP has gone down with= regards to using a single
session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with
software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable).

Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI.


Phil

On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"
<pranjal.dutta@alcatel-lucent.com> wrote:

>I second to Mustapha. Further, we had already started LDP capabilities<= br> >based approach on various FEC types support over a single LDP session >(e.g
>mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not = a
>sound approach and would raise other questions such as which adjacency = to
>be
>used for various mLdp fec types etc (as some of those has mix of ipv4 +=
>ipv6) etc.
>
>Thanks,
>Pranjal
>
>-----Original Message-----
>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
>Aissaoui, Mustapha (Mustapha)
>Sent: Monday, February 06, 2012 12: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 t= o
>advertise two different label spaces, then they must use two different<= br> >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<= br> >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 o= n
>an IPv4 session between two LSRs, =A0then 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<= br> >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 Hell= o
>adjacency but a single shared LDP session. It is not exactly what you a= re
>asking for.
>
>Regards,
>Mustapha.
>
>-----Original Message-----
>From: Shane Amante [mailto:sha= ne@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<= br> >some of your comments. =A0Specifically, 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. =A0(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 concern= ed
>about [operational] issues that may develop in, for example, v6 affecti= ng
>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 improvi= ng
>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 intuiti= ve
>to operators in lots of cases where they may expect that a configuratio= n
>change or bugs they /think/ are only going to affect one address family= ,
>really do only affect one address family. Besides, LDP Hello & Sess= ions
>timers, when set to default, are extremely relaxed (order of several >seconds), so the burden on implementations to maintain separate session= s
>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 choos= es to
>explicitly configure their device to have hellos and sessions share fat= e
>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 l= ast
>>call but I think the issues are significant enough in my view. I >>apologize if some of these comments were already raised on this mai= ling
>>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 referr= ing to a
>>loopback interface of the egress router, not any other interface. T= hat
>>is why RFC 5036 explicitly states /32 for IPv4. In my view, we shou= ld
>>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 L= SPv6)
>>matches with that of the LDP hello adjacency on the next-hop interf= ace.
>> "
>> 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 statem= ent
>>should be removed.
>>
>>
>> 3. Section 4 - LDP identifiers; third paragraph:
>> "
>> This document qualifies the first sentence of last paragraph of >> =A0 Section 2.5.2 of [RFC5036] to be per address family and theref= ore
>> =A0 updates that sentence to the following: "For a given addr= ess family
>> =A0 over which a Hello is sent, and a given label space, an LSR MU= ST
>> =A0 advertise the same transport address." This rightly enabl= es the per-
>> =A0 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 LS= R
>>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 o= ver
>>parallel links with different IPv4 transport addresses and it works= just
>>fine. I think we should remove this restriction from RFC 5036 and n= ot
>>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 mess= ages
>>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 main= tain
>>two separate Hello ajacencies per peer. In practice, each router ca= n
>>send both IPv4 and IPv6 hellos but only a single Hello adjacency mu= st 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 on= ly 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<= br> >> =A0 =A0 =A0 =A0and IPv6 transport address optional objects, but MU= ST use only
>> =A0 =A0 =A0 =A0the transport address whose address family is the s= ame as that
>> =A0 =A0 =A0 =A0of the IP packet carrying Hello.
>> "
>> MA> This is not a new issue. If I am not mistaken, this can als= o 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 a= nd
>>was left for implementations to handle. If we absolutely need to sp= ecify
>>something, maybe we should say only the first TLV in the Hello mess= age
>>is processed.
>>
>>
>> 6. Section 6.1 - Transport connection establishment "
>> 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new=
>> =A0 =A0 =A0 =A0LDP session with a remote LSR, if it has both IPv4 = and IPv6
>> =A0 =A0 =A0 =A0hello adjacencies for the same LDP Identifier (over= a dual-
>> =A0 =A0 =A0 =A0stack interface, or two or more single-stack IPv4 a= nd IPv6
>> =A0 =A0 =A0 =A0interfaces). This applies to the section 2.5.2 of R= FC5036.
>>
>> 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new=
>> =A0 =A0 =A0 =A0LDP session with a remote LSR, if they attempted tw= o TCP
>> =A0 =A0 =A0 =A0connections using IPv4 and IPv6 transport addresses=
>> =A0 =A0 =A0 =A0simultaneously.
>> "
>> MA> No need for all this if you enforce that only a single adja= cency 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=
>> =A0 well as interface addresses via ADDRESS message) from/to the p= eer
>> =A0 over an LDP session (using whatever transport), unless it has = valid
>> =A0 IPv4 and IPv6 Hello Adjacencies for that peer, as specified in=
>> =A0 section 6.2.
>> "
>> MA> I do not agree that the advertisement of IPv6 label-FEC bin= dings
>>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 t= he
>>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 interoperabili= ty
>> with IPv4-only LDP implementations), this document specifies that<= br> >> - 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<= br> >>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 differ= ent
>>address-family. In other words, an Address List TLV in the Address = (or
>>Address Withdraw) message MUST contain the addresses belonging to t= he
>>same address-family..
>> "
>> MA> This is yet another narrow interpretation of RFC 5036. Ther= e is no
>>justification for such a restriction and certainly RFC 5036 does no= t
>>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 t= hey are
>>designed to handle it. Same applies to Address list =A0TLV.
>>
>>
>> 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 handle= d in
>>existing IPv4 based LDP implementations. Maybe the authors can spec= ify
>>why duplicate link local addresses is any different.
>>
>>
>> 10. Section 9 - LDP TTL Security
>> "
>> This document also specifies that the LDP/TCP transport connection=
>> =A0 over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Secu= rity
>> =A0 Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LD= P
>> =A0 session peering established between the adjacent LSRs using Ba= sic
>> =A0 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


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

--f46d0444eadf7adc8604b8521d66-- From pranjal.dutta@alcatel-lucent.com Mon Feb 6 15:30: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 6793D11E8075 for ; Mon, 6 Feb 2012 15:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 s04JGS1nKfBW for ; Mon, 6 Feb 2012 15:30:24 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 81E0F11E8096 for ; Mon, 6 Feb 2012 15:30:14 -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 q16NTwJF028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Feb 2012 17:30: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 q16NTvCm005145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Feb 2012 04:59:57 +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, 7 Feb 2012 04:59:57 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Vishwas Manral , Phil Bedard Date: Tue, 7 Feb 2012 04:59:54 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlE/9ZRCyOAcvBShWKPdxQQTXV5QAEw4zQ 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_C584046466ED224CA92C1BC3313B963E09EFE8D664INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 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, 06 Feb 2012 23:30:26 -0000 --_000_C584046466ED224CA92C1BC3313B963E09EFE8D664INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That means in mobility backhauls if we are running 10K adjacencies today, t= his draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante= ; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using different= instances of LDP itself or something in between, in which case we can use = different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard > wrote: I understand the road LDP has gone down with regards to using a single session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" >= wrote: >I second to Mustapha. Further, we had already started LDP capabilities >based approach on various FEC types support over a single LDP session >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a >sound approach and would raise other questions such as which adjacency to >be >used for various mLdp fec types etc (as some of those has mix of ipv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_C584046466ED224CA92C1BC3313B963E09EFE8D664INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That means in mobility backhauls if we= are running 10K adjacencies today, this draft imposes us to run 20K adjacencies= in case of IPV6.

 

Thanks,

Pranjal

 

From: Vishwas = Manral [mailto:vishwas.ietf@gmail.com]
Sent: Monday, February 06, 2= 012 1:12 PM
To: Phil Bedard
Cc: Dutta, Pranjal K (Pranja= l); Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 

Hi Phil,

You are right. If we want minimal fate-sharing, we could be using different instances of LDP itself or something in between, in which case we can use different LSR id/ MT extension etc.

The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session.

The draft also in section 7, mentions the use of LDP capability.

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard <bedard.phil@gmail.com> wrote:<= o:p>

I understand the road LDP has gone down with regards to using a sin= gle
session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with
software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable).

Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI.


Phil

On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"=

<pranjal.dut= ta@alcatel-lucent.com> wrote:

>I second to Mustapha. Further, we had already started LDP capabilities<= br> >based approach on various FEC types support over a single LDP session >(e.g
>mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not = a
>sound approach and would raise other questions such as which adjacency = to
>be
>used for various mLdp fec types etc (as some of those has mix of ipv4 +=
>ipv6) etc.
>
>Thanks,
>Pranjal
>
>-----Original Message-----
>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]= On Behalf Of
>Aissaoui, Mustapha (Mustapha)
>Sent: Monday, February 06, 2012 12: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 t= o
>advertise two different label spaces, then they must use two different<= br> >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<= br> >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 o= n
>an IPv4 session between two LSRs,  then we should consider extendi= ng 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<= br> >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 Hell= o
>adjacency but a single shared LDP session. It is not exactly what you a= re
>asking for.
>
>Regards,
>Mustapha.
>
>-----Original Message-----
>From: Shane Amante [mailto:sha= ne@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<= br> >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 affecti= ng
>the exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As o= ne
>more concrete example, 6man/v6ops are only right now working on improvi= ng
>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 intuiti= ve
>to operators in lots of cases where they may expect that a configuratio= n
>change or bugs they /think/ are only going to affect one address family= ,
>really do only affect one address family. Besides, LDP Hello & Sess= ions
>timers, when set to default, are extremely relaxed (order of several >seconds), so the burden on implementations to maintain separate session= s
>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 choos= es to
>explicitly configure their device to have hellos and sessions share fat= e
>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 l= ast
>>call but I think the issues are significant enough in my view. I >>apologize if some of these comments were already raised on this mai= ling
>>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 referr= ing to a
>>loopback interface of the egress router, not any other interface. T= hat
>>is why RFC 5036 explicitly states /32 for IPv4. In my view, we shou= ld
>>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 interf= ace.
>> "
>> 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 statem= ent
>>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 LS= R
>>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 o= ver
>>parallel links with different IPv4 transport addresses and it works just
>>fine. I think we should remove this restriction from RFC 5036 and n= ot
>>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 mess= ages
>>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 main= tain
>>two separate Hello ajacencies per peer. In practice, each router ca= n
>>send both IPv4 and IPv6 hellos but only a single Hello adjacency mu= st 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 on= ly 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<= br> >>        and IPv6 transport address optional objects, but MUST use only
>>        the transport address whose address fam= ily 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 als= o 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 a= nd
>>was left for implementations to handle. If we absolutely need to specify
>>something, maybe we should say only the first TLV in the Hello mess= age
>>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 ha= s 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 sectio= n 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 transpo= rt 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 th= e peer
>>   over an LDP session (using whatever transport), unless it h= as 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 t= he
>>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 interoperabili= ty
>> with IPv4-only LDP implementations), this document specifies that<= br> >> - 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<= br> >>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 differ= ent
>>address-family. In other words, an Address List TLV in the Address = (or
>>Address Withdraw) message MUST contain the addresses belonging to t= he
>>same address-family..
>> "
>> MA> This is yet another narrow interpretation of RFC 5036. Ther= e is no
>>justification for such a restriction and certainly RFC 5036 does no= t
>>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 handle= d in
>>existing IPv4 based LDP implementations. Maybe the authors can spec= ify
>>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


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

 

--_000_C584046466ED224CA92C1BC3313B963E09EFE8D664INBANSXCHMBSA_-- From vishwas.ietf@gmail.com Mon Feb 6 15:50: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 3DFA021F86B3 for ; Mon, 6 Feb 2012 15:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057, 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 guQeRQO-548Y for ; Mon, 6 Feb 2012 15:50:48 -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 EE8B621F85FC for ; Mon, 6 Feb 2012 15:50:26 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9071806obb.31 for ; Mon, 06 Feb 2012 15:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JUgtMXHAopVQk50RyXDUVXeuQYB/CtyHvNQL3y6wz6I=; b=GS3G7kSgoLZ2bSDvX5AyijZWrJkUgzSnJH9yQOu3QQe+BdEvvaO4cz7fv5ZuwVlF7U gZvada8qxe+4qh10Dg5jOWWc47JnAVvbEYge5THYcJcHg7f0McWuBPbq0mCH745yfIWI am5dSuM8bPGBrRYqsZglIpCbyvsNb3NaVD3KY= MIME-Version: 1.0 Received: by 10.182.216.101 with SMTP id op5mr18548576obc.54.1328572226580; Mon, 06 Feb 2012 15:50:26 -0800 (PST) Received: by 10.182.28.196 with HTTP; Mon, 6 Feb 2012 15:50:26 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Feb 2012 15:50:26 -0800 Message-ID: From: Vishwas Manral To: "Dutta, Pranjal K (Pranjal)" Content-Type: multipart/alternative; boundary=f46d0447864b9fb24b04b8545310 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, 06 Feb 2012 23:50:50 -0000 --f46d0447864b9fb24b04b8545310 Content-Type: text/plain; charset=ISO-8859-1 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we want complete separation. Ofcourse the assumption is we will have all adjacencies using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) < pranjal.dutta@alcatel-lucent.com> wrote: > That means in mobility backhauls if we are running 10K adjacencies > today, this draft imposes us to run 20K adjacencies in case of IPV6. **** > > ** ** > > Thanks,**** > > Pranjal**** > > ** ** > ------------------------------ > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Monday, February 06, 2012 1:12 PM > *To:* Phil Bedard > *Cc:* Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane > Amante; mpls@ietf.org > > *Subject:* Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > **** > > ** ** > > Hi Phil, > > You are right. If we want minimal fate-sharing, we could be using > different instances of LDP itself or something in between, in which case we > can use different LSR id/ MT extension etc. > > The draft talks about the case based on current RFC5036, where we can > currently support multiple hello adjacencies and a single LDP session. > > The draft also in section 7, mentions the use of LDP capability. > > Thanks, > Vishwas**** > > On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard > wrote:**** > > I understand the road LDP has gone down with regards to using a single > session/adjacency to advertise multiple families of FECs, similar to BGP. > Like I said, many providers these days have taken steps to separate their > IPv6 and IPv4 control planes, usually for shared-fate concerns with > software defects and to just keep things simpler for operational folks to > deal with (which is somewhat debatable). > > Mustapha mentioned BGP but the fact is providers today use two different > sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for > either to advertise both NLRI. > > > Phil > > On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"**** > > wrote: > > >I second to Mustapha. Further, we had already started LDP capabilities > >based approach on various FEC types support over a single LDP session > >(e.g > >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a > >sound approach and would raise other questions such as which adjacency to > >be > >used for various mLdp fec types etc (as some of those has mix of ipv4 + > >ipv6) etc. > > > >Thanks, > >Pranjal > > > >-----Original Message----- > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > >Aissaoui, Mustapha (Mustapha) > >Sent: Monday, February 06, 2012 12: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. > >> ====================================================================== > >> ================= > >> > >> 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. > >> > --f46d0447864b9fb24b04b8545310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's correct Pranjal.

The other option is to have 20k adjacen= cies and 20k sessions, if we want complete separation. Ofcourse the assumpt= ion is we will have all adjacencies using both IPv4 and IPv6.

Thanks= ,
Vishwas

On Mon, Feb 6, 2012 at 3:29 PM, D= utta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wr= ote:

That means in mobility backha= uls if we are running 10K adjacencies today, this draft imposes us to run 20K adjacencies= in case of IPV6.

=A0

Thanks,<= /font>

Pranjal<= /font>

=A0

From: Vishwas Ma= nral [mailto:vishwas= .ietf@gmail.com]
Sent: Monday, February 06, 2= 012 1:12 PM
To: Phil Bedard
Cc: Dutta, Pranjal K (Pranja= l); Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org


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

=A0

Hi Phil,

You are right. If we want minimal fate-sharing, we could be using different instances of LDP itself or something in between, in which case we can use different LSR id/ MT extension etc.

The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session.

The draft also in section 7, mentions the use of LDP capability.

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard <bedard.phil@gmail.c= om> wrote:

I understand the road LDP has gone down with regards= to using a single
session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with
software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable).

Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI.


Phil

On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"

<pranjal.dutta@alcatel-lucent.com> wrote:

>I second to Mustapha. Further, we had already started LDP capabilities<= br> >based approach on various FEC types support over a single LDP session >(e.g
>mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not = a
>sound approach and would raise other questions such as which adjacency = to
>be
>used for various mLdp fec types etc (as some of those has mix of ipv4 +=
>ipv6) etc.
>
>Thanks,
>Pranjal
>
>-----Original Message-----
>From: mpls-b= ounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of
>Aissaoui, Mustapha (Mustapha)
>Sent: Monday, February 06, 2012 12: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 t= o
>advertise two different label spaces, then they must use two different<= br> >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<= br> >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 o= n
>an IPv4 session between two LSRs, =A0then 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<= br> >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 Hell= o
>adjacency but a single shared LDP session. It is not exactly what you a= re
>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<= br> >some of your comments. =A0Specifically, 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. =A0(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 concern= ed
>about [operational] issues that may develop in, for example, v6 affecti= ng
>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 improvi= ng
>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 intuiti= ve
>to operators in lots of cases where they may expect that a configuratio= n
>change or bugs they /think/ are only going to affect one address family= ,
>really do only affect one address family. Besides, LDP Hello & Sess= ions
>timers, when set to default, are extremely relaxed (order of several >seconds), so the burden on implementations to maintain separate session= s
>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 choos= es to
>explicitly configure their device to have hellos and sessions share fat= e
>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 l= ast
>>call but I think the issues are significant enough in my view. I >>apologize if some of these comments were already raised on this mai= ling
>>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 referr= ing to a
>>loopback interface of the egress router, not any other interface. T= hat
>>is why RFC 5036 explicitly states /32 for IPv4. In my view, we shou= ld
>>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 L= SPv6)
>>matches with that of the LDP hello adjacency on the next-hop interf= ace.
>> "
>> 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 statem= ent
>>should be removed.
>>
>>
>> 3. Section 4 - LDP identifiers; third paragraph:
>> "
>> This document qualifies the first sentence of last paragraph of >> =A0 Section 2.5.2 of [RFC5036] to be per address family and therefore
>> =A0 updates that sentence to the following: "For a given address family
>> =A0 over which a Hello is sent, and a given label space, an LSR MUST
>> =A0 advertise the same transport address." This rightly enables the per-
>> =A0 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 LS= R
>>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 o= ver
>>parallel links with different IPv4 transport addresses and it works just
>>fine. I think we should remove this restriction from RFC 5036 and n= ot
>>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 mess= ages
>>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 main= tain
>>two separate Hello ajacencies per peer. In practice, each router ca= n
>>send both IPv4 and IPv6 hellos but only a single Hello adjacency mu= st 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 on= ly 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<= br> >> =A0 =A0 =A0 =A0and IPv6 transport address optional objects, but MUST use only
>> =A0 =A0 =A0 =A0the transport address whose address family is the same as that
>> =A0 =A0 =A0 =A0of the IP packet carrying Hello.
>> "
>> MA> This is not a new issue. If I am not mistaken, this can als= o 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 a= nd
>>was left for implementations to handle. If we absolutely need to specify
>>something, maybe we should say only the first TLV in the Hello mess= age
>>is processed.
>>
>>
>> 6. Section 6.1 - Transport connection establishment "
>> 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new=
>> =A0 =A0 =A0 =A0LDP session with a remote LSR, if it has both IPv4 and IPv6
>> =A0 =A0 =A0 =A0hello adjacencies for the same LDP Identifier (over a dual-
>> =A0 =A0 =A0 =A0stack interface, or two or more single-stack IPv4 and IPv6
>> =A0 =A0 =A0 =A0interfaces). This applies to the section 2.5.2 of RFC5036.
>>
>> 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new=
>> =A0 =A0 =A0 =A0LDP session with a remote LSR, if they attempted two TCP
>> =A0 =A0 =A0 =A0connections using IPv4 and IPv6 transport addresses
>> =A0 =A0 =A0 =A0simultaneously.
>> "
>> 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=
>> =A0 well as interface addresses via ADDRESS message) from/to the peer
>> =A0 over an LDP session (using whatever transport), unless it has valid
>> =A0 IPv4 and IPv6 Hello Adjacencies for that peer, as specified in=
>> =A0 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 t= he
>>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 interoperabili= ty
>> with IPv4-only LDP implementations), this document specifies that<= br> >> - 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<= br> >>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 differ= ent
>>address-family. In other words, an Address List TLV in the Address = (or
>>Address Withdraw) message MUST contain the addresses belonging to t= he
>>same address-family..
>> "
>> MA> This is yet another narrow interpretation of RFC 5036. Ther= e is no
>>justification for such a restriction and certainly RFC 5036 does no= t
>>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 t= hey are
>>designed to handle it. Same applies to Address list =A0TLV.
>>
>>
>> 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 handle= d in
>>existing IPv4 based LDP implementations. Maybe the authors can spec= ify
>>why duplicate link local addresses is any different.
>>
>>
>> 10. Section 9 - LDP TTL Security
>> "
>> This document also specifies that the LDP/TCP transport connection=
>> =A0 over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security
>> =A0 Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LD= P
>> =A0 session peering established between the adjacent LSRs using Basic
>> =A0 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.
>>


--f46d0447864b9fb24b04b8545310-- From pranjal.dutta@alcatel-lucent.com Mon Feb 6 15:58: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 C3F8E11E80BB for ; Mon, 6 Feb 2012 15:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.334, 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 T4Gww85iS3vE for ; Mon, 6 Feb 2012 15:58:42 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6EF11E8080 for ; Mon, 6 Feb 2012 15:58:42 -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 q16NwO6K004086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Feb 2012 17:58:27 -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 q16NwOPC032377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Feb 2012 05:28:24 +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, 7 Feb 2012 05:28:24 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Vishwas Manral Date: Tue, 7 Feb 2012 05:28:21 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlKhzOFi1N82YoRJaGlVnJxECj0gAAKKJQ 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_C584046466ED224CA92C1BC3313B963E09EFE8D667INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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, 06 Feb 2012 23:58:44 -0000 --_000_C584046466ED224CA92C1BC3313B963E09EFE8D667INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 woul= d continue over the single ldp/tcp session for IPV4 and IPV6. Having IPV4 and IPV6 specific hello adjacencies over a link would only deci= de 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 ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 3:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we want co= mplete separation. Ofcourse the assumption is we will have all adjacencies = using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) > wrote: That means in mobility backhauls if we are running 10K adjacencies today, t= his draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante= ; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using different= instances of LDP itself or something in between, in which case we can use = different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard > wrote: I understand the road LDP has gone down with regards to using a single session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" >= wrote: >I second to Mustapha. Further, we had already started LDP capabilities >based approach on various FEC types support over a single LDP session >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a >sound approach and would raise other questions such as which adjacency to >be >used for various mLdp fec types etc (as some of those has mix of ipv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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. >> --_000_C584046466ED224CA92C1BC3313B963E09EFE8D667INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would rather for complete separation with multiple lsr-id because having separate link adjacencies does not real= ly solved any problem.

Since hello adjacencies are associated with a link, still fate sharing would continue over the single ldp/tcp sess= ion 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

 

From: Vishwas = Manral [mailto:vishwas.ietf@gmail.com]
Sent: Monday, February 06, 2= 012 3:50 PM
To: Dutta, Pranjal K (Pranja= l)
Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 

That's correct Pr= anjal.

The other option is to have 20k adjacencies and 20k sessions, if we want complete separation. Ofcourse the assumption is we will have all adjacencie= s using both IPv4 and IPv6.

Thanks,
Vishwas

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

That means in mobility backhauls if we are running 10K adjacenc= ies today, this draft imposes us to run 20K adjacencies in case of IPV6.

 

Thanks,

Pranjal

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail= .com]
Sent: Monday, February 06, 2= 012 1:12 PM
To: Phil Bedard
Cc: Dutta, Pranjal K (Pranja= l); Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org


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

 

Hi Phil,=

You are right. If we want minimal fate-sharing, we could be using different instances of LDP itself or something in between, in which case we can use different LSR id/ MT extension etc.

The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session.

The draft also in section 7, mentions the use of LDP capability.

Thanks,
Vishwas

On Mon, = Feb 6, 2012 at 12:44 PM, Phil Bedard <bedard.phil@gmail.com> wrote:

I unders= tand the road LDP has gone down with regards to using a single
session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with
software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable).

Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI.


Phil

On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"=

<pranjal.= dutta@alcatel-lucent.com> wrote:

>I second to Mustapha. Further, we had already started LDP capabilities<= br> >based approach on various FEC types support over a single LDP session >(e.g
>mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not = a
>sound approach and would raise other questions such as which adjacency = to
>be
>used for various mLdp fec types etc (as some of those has mix of ipv4 +=
>ipv6) etc.
>
>Thanks,
>Pranjal
>
>-----Original Message-----
>From: mpls-b= ounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of
>Aissaoui, Mustapha (Mustapha)
>Sent: Monday, February 06, 2012 12: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 t= o
>advertise two different label spaces, then they must use two different<= br> >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<= br> >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 o= n
>an IPv4 session between two LSRs,  then we should consider extendi= ng 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<= br> >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 Hell= o
>adjacency but a single shared LDP session. It is not exactly what you a= re
>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<= br> >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 affecti= ng
>the exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As o= ne
>more concrete example, 6man/v6ops are only right now working on improvi= ng
>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 intuiti= ve
>to operators in lots of cases where they may expect that a configuratio= n
>change or bugs they /think/ are only going to affect one address family= ,
>really do only affect one address family. Besides, LDP Hello & Sess= ions
>timers, when set to default, are extremely relaxed (order of several >seconds), so the burden on implementations to maintain separate session= s
>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 choos= es to
>explicitly configure their device to have hellos and sessions share fat= e
>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 l= ast
>>call but I think the issues are significant enough in my view. I >>apologize if some of these comments were already raised on this mai= ling
>>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 referr= ing to a
>>loopback interface of the egress router, not any other interface. T= hat
>>is why RFC 5036 explicitly states /32 for IPv4. In my view, we shou= ld
>>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 interf= ace.
>> "
>> 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 statem= ent
>>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 LS= R
>>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 o= ver
>>parallel links with different IPv4 transport addresses and it works just
>>fine. I think we should remove this restriction from RFC 5036 and n= ot
>>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 mess= ages
>>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 main= tain
>>two separate Hello ajacencies per peer. In practice, each router ca= n
>>send both IPv4 and IPv6 hellos but only a single Hello adjacency mu= st 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 on= ly 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<= br> >>        and IPv6 transport address optional objects, but MUST use only
>>        the transport address whose address fam= ily 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 als= o 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 a= nd
>>was left for implementations to handle. If we absolutely need to specify
>>something, maybe we should say only the first TLV in the Hello mess= age
>>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 ha= s 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 sectio= n 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 transpo= rt 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 th= e peer
>>   over an LDP session (using whatever transport), unless it h= as 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 t= he
>>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 interoperabili= ty
>> with IPv4-only LDP implementations), this document specifies that<= br> >> - 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<= br> >>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 differ= ent
>>address-family. In other words, an Address List TLV in the Address = (or
>>Address Withdraw) message MUST contain the addresses belonging to t= he
>>same address-family..
>> "
>> MA> This is yet another narrow interpretation of RFC 5036. Ther= e is no
>>justification for such a restriction and certainly RFC 5036 does no= t
>>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 handle= d in
>>existing IPv4 based LDP implementations. Maybe the authors can spec= ify
>>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.
>>

 

--_000_C584046466ED224CA92C1BC3313B963E09EFE8D667INBANSXCHMBSA_-- From vishwas.ietf@gmail.com Mon Feb 6 16:03: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 48D6111E80C8 for ; Mon, 6 Feb 2012 16:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053, 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 BxKFAdhCuqnb for ; Mon, 6 Feb 2012 16:03:12 -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 847B311E8080 for ; Mon, 6 Feb 2012 16:03:10 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9088095obb.31 for ; Mon, 06 Feb 2012 16:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c0T40FFn8A6Jad1DtHKKLHh5ItXpdQzepE1b8fHGv+o=; b=JvjDn2ZC3WLTOu6RcLteGH5IP9txHXcE6E0DRJ3G15S5z1pJK9tGeM09sWALSm/rFk wPlRth8AhU/ja8Eh65qaoLESWtUo1Vp5BCQ7OIBMpfli3XJvXmkdvzX9UT3/P2HNedSq qKVnDlIAzeu95foXWMMDm0ROeFYcyLof3oVFE= MIME-Version: 1.0 Received: by 10.182.76.229 with SMTP id n5mr18668596obw.14.1328572990149; Mon, 06 Feb 2012 16:03:10 -0800 (PST) Received: by 10.182.28.196 with HTTP; Mon, 6 Feb 2012 16:03:09 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Feb 2012 16:03:09 -0800 Message-ID: From: Vishwas Manral To: "Dutta, Pranjal K (Pranjal)" Content-Type: multipart/alternative; boundary=f46d044785d522d58e04b85481ad 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: Tue, 07 Feb 2012 00:03:14 -0000 --f46d044785d522d58e04b85481ad Content-Type: text/plain; charset=ISO-8859-1 Good points Pranjal. The idea is simple, the current specs allow multiple adjacencies and still have a single session. We are allowing IPv4 and IPv6 adjacencies to check forwarding is working and then use only one session, based on what the operator prioritizes the Address family usage. It is very similar to the usecase of multiple parallel links, between the same set of devices example as given in RFC 5036. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) < pranjal.dutta@alcatel-lucent.com> wrote: > 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**** > > ** ** > ------------------------------ > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Monday, February 06, 2012 3:50 PM > *To:* Dutta, Pranjal K (Pranjal) > *Cc:* Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; > mpls@ietf.org > > *Subject:* Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > **** > > ** ** > > That's correct Pranjal. > > The other option is to have 20k adjacencies and 20k sessions, if we want > complete separation. Ofcourse the assumption is we will have all > adjacencies using both IPv4 and IPv6. > > Thanks, > Vishwas**** > > On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) < > pranjal.dutta@alcatel-lucent.com> wrote:**** > > That means in mobility backhauls if we are running 10K adjacencies today, > this draft imposes us to run 20K adjacencies in case of IPV6. **** > > **** > > Thanks,**** > > Pranjal**** > > **** > ------------------------------ > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Monday, February 06, 2012 1:12 PM > *To:* Phil Bedard > *Cc:* Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane > Amante; mpls@ietf.org**** > > > *Subject:* Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06**** > > **** > > Hi Phil, > > You are right. If we want minimal fate-sharing, we could be using > different instances of LDP itself or something in between, in which case we > can use different LSR id/ MT extension etc. > > The draft talks about the case based on current RFC5036, where we can > currently support multiple hello adjacencies and a single LDP session. > > The draft also in section 7, mentions the use of LDP capability. > > Thanks, > Vishwas**** > > On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard > wrote:**** > > I understand the road LDP has gone down with regards to using a single > session/adjacency to advertise multiple families of FECs, similar to BGP. > Like I said, many providers these days have taken steps to separate their > IPv6 and IPv4 control planes, usually for shared-fate concerns with > software defects and to just keep things simpler for operational folks to > deal with (which is somewhat debatable). > > Mustapha mentioned BGP but the fact is providers today use two different > sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for > either to advertise both NLRI. > > > Phil > > On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"**** > > wrote: > > >I second to Mustapha. Further, we had already started LDP capabilities > >based approach on various FEC types support over a single LDP session > >(e.g > >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a > >sound approach and would raise other questions such as which adjacency to > >be > >used for various mLdp fec types etc (as some of those has mix of ipv4 + > >ipv6) etc. > > > >Thanks, > >Pranjal > > > >-----Original Message----- > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > >Aissaoui, Mustapha (Mustapha) > >Sent: Monday, February 06, 2012 12: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. > >> ====================================================================== > >> ================= > >> > >> 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. > >>**** > > ** ** > --f46d044785d522d58e04b85481ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good points Pranjal.

The idea is simple, the current specs allow mul= tiple adjacencies and still have a single session. We are allowing IPv4 and= IPv6 adjacencies to check forwarding is working and then use only one sess= ion, based on what the operator prioritizes the Address family usage. It is= very similar to the usecase of multiple parallel links, between the same s= et of devices example as given in RFC 5036.

Thanks,
Vishwas

On Mon, Feb 6, 201= 2 at 3:58 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

I would rather for complete s= eparation with multiple lsr-id because having separate link adjacencies does not real= ly solved any problem.

Since hello adjacencies are a= ssociated with a link, still fate sharing would continue over the single ldp/tcp sess= ion 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.

=A0

Thanks,<= /font>

Pranjal<= /font>

=A0

From: Vishwas Ma= nral [mailto:vishwas= .ietf@gmail.com]
Sent: Monday, February 06, 2= 012 3:50 PM
To: Dutta, Pranjal K (Pranja= l)
Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org


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

=A0

That's correct Pr= anjal.

The other option is to have 20k adjacencies and 20k sessions, if we want complete separation. Ofcourse the assumption is we will have all adjacencie= s using both IPv4 and IPv6.

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pr= anjal) <pranjal.dutta@alcatel-lucent.com> wrote:

That means in mobility backha= uls if we are running 10K adjacencies today, this draft imposes us to run 20K adjacencies in case of IPV6.

=A0

Thanks,<= u>

Pranjal<= u>

=A0

From: Vishwas Ma= nral [mailto:vi= shwas.ietf@gmail.com]
Sent: Monday, February 06, 2= 012 1:12 PM
To: Phil Bedard
Cc: Dutta, Pranjal K (Pranja= l); Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org


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

=A0

Hi Phil,

You are right. If we want minimal fate-sharing, we could be using different instances of LDP itself or something in between, in which case we can use different LSR id/ MT extension etc.

The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session.

The draft also in section 7, mentions the use of LDP capability.

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard <bedard.phil@gmail.com> wrote:=

I understand the road LDP has gone down with regards to using a single
session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with
software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable).

Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI.


Phil

On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"

<pranjal.dutta@alcatel-lucent.com> wrote:

>I second to Mustapha. Further, we had already started LDP capabilities<= br> >based approach on various FEC types support over a single LDP session >(e.g
>mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not = a
>sound approach and would raise other questions such as which adjacency = to
>be
>used for various mLdp fec types etc (as some of those has mix of ipv4 +=
>ipv6) etc.
>
>Thanks,
>Pranjal
>
>-----Original Message-----
>From: mpls-b= ounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of
>Aissaoui, Mustapha (Mustapha)
>Sent: Monday, February 06, 2012 12: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 t= o
>advertise two different label spaces, then they must use two different<= br> >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<= br> >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 o= n
>an IPv4 session between two LSRs, =A0then 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<= br> >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 Hell= o
>adjacency but a single shared LDP session. It is not exactly what you a= re
>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<= br> >some of your comments. =A0Specifically, 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. =A0(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 concern= ed
>about [operational] issues that may develop in, for example, v6 affecti= ng
>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 improvi= ng
>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 intuiti= ve
>to operators in lots of cases where they may expect that a configuratio= n
>change or bugs they /think/ are only going to affect one address family= ,
>really do only affect one address family. Besides, LDP Hello & Sess= ions
>timers, when set to default, are extremely relaxed (order of several >seconds), so the burden on implementations to maintain separate session= s
>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 choos= es to
>explicitly configure their device to have hellos and sessions share fat= e
>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 l= ast
>>call but I think the issues are significant enough in my view. I >>apologize if some of these comments were already raised on this mai= ling
>>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 referr= ing to a
>>loopback interface of the egress router, not any other interface. T= hat
>>is why RFC 5036 explicitly states /32 for IPv4. In my view, we shou= ld
>>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 L= SPv6)
>>matches with that of the LDP hello adjacency on the next-hop interf= ace.
>> "
>> 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 statem= ent
>>should be removed.
>>
>>
>> 3. Section 4 - LDP identifiers; third paragraph:
>> "
>> This document qualifies the first sentence of last paragraph of >> =A0 Section 2.5.2 of [RFC5036] to be per address family and therefore
>> =A0 updates that sentence to the following: "For a given address family
>> =A0 over which a Hello is sent, and a given label space, an LSR MUST
>> =A0 advertise the same transport address." This rightly enables the per-
>> =A0 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 LS= R
>>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 o= ver
>>parallel links with different IPv4 transport addresses and it works just
>>fine. I think we should remove this restriction from RFC 5036 and n= ot
>>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 mess= ages
>>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 main= tain
>>two separate Hello ajacencies per peer. In practice, each router ca= n
>>send both IPv4 and IPv6 hellos but only a single Hello adjacency mu= st 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 on= ly 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<= br> >> =A0 =A0 =A0 =A0and IPv6 transport address optional objects, but MUST use only
>> =A0 =A0 =A0 =A0the transport address whose address family is the same as that
>> =A0 =A0 =A0 =A0of the IP packet carrying Hello.
>> "
>> MA> This is not a new issue. If I am not mistaken, this can als= o 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 a= nd
>>was left for implementations to handle. If we absolutely need to specify
>>something, maybe we should say only the first TLV in the Hello mess= age
>>is processed.
>>
>>
>> 6. Section 6.1 - Transport connection establishment "
>> 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new=
>> =A0 =A0 =A0 =A0LDP session with a remote LSR, if it has both IPv4 and IPv6
>> =A0 =A0 =A0 =A0hello adjacencies for the same LDP Identifier (over a dual-
>> =A0 =A0 =A0 =A0stack interface, or two or more single-stack IPv4 and IPv6
>> =A0 =A0 =A0 =A0interfaces). This applies to the section 2.5.2 of RFC5036.
>>
>> 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new=
>> =A0 =A0 =A0 =A0LDP session with a remote LSR, if they attempted two TCP
>> =A0 =A0 =A0 =A0connections using IPv4 and IPv6 transport addresses
>> =A0 =A0 =A0 =A0simultaneously.
>> "
>> 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=
>> =A0 well as interface addresses via ADDRESS message) from/to the peer
>> =A0 over an LDP session (using whatever transport), unless it has valid
>> =A0 IPv4 and IPv6 Hello Adjacencies for that peer, as specified in=
>> =A0 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 t= he
>>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 interoperabili= ty
>> with IPv4-only LDP implementations), this document specifies that<= br> >> - 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<= br> >>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 differ= ent
>>address-family. In other words, an Address List TLV in the Address = (or
>>Address Withdraw) message MUST contain the addresses belonging to t= he
>>same address-family..
>> "
>> MA> This is yet another narrow interpretation of RFC 5036. Ther= e is no
>>justification for such a restriction and certainly RFC 5036 does no= t
>>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 t= hey are
>>designed to handle it. Same applies to Address list =A0TLV.
>>
>>
>> 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 handle= d in
>>existing IPv4 based LDP implementations. Maybe the authors can spec= ify
>>why duplicate link local addresses is any different.
>>
>>
>> 10. Section 9 - LDP TTL Security
>> "
>> This document also specifies that the LDP/TCP transport connection=
>> =A0 over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security
>> =A0 Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LD= P
>> =A0 session peering established between the adjacent LSRs using Basic
>> =A0 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.
>>

=A0


--f46d044785d522d58e04b85481ad-- From Tina.Tsou.Zouting@huawei.com Mon Feb 6 16:29: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 4AEA711E80B3 for ; Mon, 6 Feb 2012 16:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.154, 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 SbJZLq3Qkprk for ; Mon, 6 Feb 2012 16:29:16 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2797111E8085 for ; Mon, 6 Feb 2012 16:29:14 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYZ00CH9YOIIC@szxga05-in.huawei.com> for mpls@ietf.org; Tue, 07 Feb 2012 08:29:06 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYZ00EOEYOI7T@szxga05-in.huawei.com> for mpls@ietf.org; Tue, 07 Feb 2012 08:29:06 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGS10424; Tue, 07 Feb 2012 08:29:04 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 07 Feb 2012 08:29:01 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 07 Feb 2012 08:29:03 +0800 Date: Tue, 07 Feb 2012 00:28:44 +0000 From: Tina TSOU In-reply-to: To: Vishwas Manral Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8ypVK6JoZ4qhs+CdRD9V9g)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-index: AcziyUTVUtTomjEtROapf+FH1ToxH///00cAgAQt5ICAAAJqAIAABCUAgAAHlwCAACZ+AIAABb0AgAACNoCAAAFXgIAAjUNb X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: 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: Tue, 07 Feb 2012 00:29:18 -0000 --Boundary_(ID_8ypVK6JoZ4qhs+CdRD9V9g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Is it something like that 3GPP takes one PDP for both IPv4 and IPv6? We take the similar approach? Sent from my iPad On Feb 6, 2012, at 4:03 PM, "Vishwas Manral" > wrote: Good points Pranjal. The idea is simple, the current specs allow multiple adjacencies and still have a single session. We are allowing IPv4 and IPv6 adjacencies to check forwarding is working and then use only one session, based on what the operator prioritizes the Address family usage. It is very similar to the usecase of multiple parallel links, between the same set of devices example as given in RFC 5036. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) > wrote: 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 ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 3:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we want complete separation. Ofcourse the assumption is we will have all adjacencies using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) > wrote: That means in mobility backhauls if we are running 10K adjacencies today, this draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using different instances of LDP itself or something in between, in which case we can use different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we can currently support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard > wrote: I understand the road LDP has gone down with regards to using a single session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" > wrote: >I second to Mustapha. Further, we had already started LDP capabilities >based approach on various FEC types support over a single LDP session >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a >sound approach and would raise other questions such as which adjacency to >be >used for various mLdp fec types etc (as some of those has mix of ipv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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. >> ====================================================================== >> ================= >> >> 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. >> --Boundary_(ID_8ypVK6JoZ4qhs+CdRD9V9g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Is it something like that 3GPP takes one PDP for both IPv4 and IPv6? We take the similar approach?

Sent from my iPad
Good points Pranjal.

The idea is simple, the current specs allow multiple adjacencies and still have a single session. We are allowing IPv4 and IPv6 adjacencies to check forwarding is working and then use only one session, based on what the operator prioritizes the Address family usage. It is very similar to the usecase of multiple parallel links, between the same set of devices example as given in RFC 5036.

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

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

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Monday, February 06, 2012 3:50 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org


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

 

That's correct Pranjal.

The other option is to have 20k adjacencies and 20k sessions, if we want complete separation. Ofcourse the assumption is we will have all adjacencies using both IPv4 and IPv6.

Thanks,
Vishwas

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

That means in mobility backhauls if we are running 10K adjacencies today, this draft imposes us to run 20K adjacencies in case of IPV6.

 

Thanks,

Pranjal

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Monday, February 06, 2012 1:12 PM
To: Phil Bedard
Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org


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

 

Hi Phil,

You are right. If we want minimal fate-sharing, we could be using different instances of LDP itself or something in between, in which case we can use different LSR id/ MT extension etc.

The draft talks about the case based on current RFC5036, where we can currently support multiple hello adjacencies and a single LDP session.

The draft also in section 7, mentions the use of LDP capability.

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard <bedard.phil@gmail.com> wrote:

I understand the road LDP has gone down with regards to using a single
session/adjacency to advertise multiple families of FECs, similar to BGP.
Like I said, many providers these days have taken steps to separate their
IPv6 and IPv4 control planes, usually for shared-fate concerns with
software defects and to just keep things simpler for operational folks to
deal with (which is somewhat debatable).

Mustapha mentioned BGP but the fact is providers today use two different
sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for
either to advertise both NLRI.


Phil

On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"

<pranjal.dutta@alcatel-lucent.com> wrote:

>I second to Mustapha. Further, we had already started LDP capabilities
>based approach on various FEC types support over a single LDP session
>(e.g
>mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a
>sound approach and would raise other questions such as which adjacency to
>be
>used for various mLdp fec types etc (as some of those has mix of ipv4 +
>ipv6) etc.
>
>Thanks,
>Pranjal
>
>-----Original Message-----
>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
>Aissaoui, Mustapha (Mustapha)
>Sent: Monday, February 06, 2012 12: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.
>> ======================================================================
>> =================
>>
>> 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.
>>

 


--Boundary_(ID_8ypVK6JoZ4qhs+CdRD9V9g)-- From lizhong.jin@zte.com.cn Mon Feb 6 19:23: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 CB35A21F8591 for ; Mon, 6 Feb 2012 19:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.39 X-Spam-Level: X-Spam-Status: No, score=-101.39 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9lqlQo8J847Z for ; Mon, 6 Feb 2012 19:23:42 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6A63621F858A for ; Mon, 6 Feb 2012 19:23:42 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690806486374; Tue, 7 Feb 2012 10:56:53 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 83373.4734952721; Tue, 7 Feb 2012 11:23:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q173NRqV055633; Tue, 7 Feb 2012 11:23:27 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: pranjal.dutta@alcatel-lucent.com, vishwas.ietf@gmail.com, mustapha.aissaoui@alcatel-lucent.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 7 Feb 2012 11:22:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-07 11:23:29, Serialize complete at 2012-02-07 11:23:29 Content-Type: multipart/alternative; boundary="=_alternative 0012A0EB4825799D_=" X-MAIL: mse01.zte.com.cn q173NRqV055633 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: Tue, 07 Feb 2012 03:23:43 -0000 This is a multipart message in MIME format. --=_alternative 0012A0EB4825799D_= Content-Type: text/plain; charset="US-ASCII" 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 0012A0EB4825799D_= Content-Type: text/html; charset="US-ASCII"
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 0012A0EB4825799D_=-- From skraza@cisco.com Mon Feb 6 20:49: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 2C25011E8086 for ; Mon, 6 Feb 2012 20:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.202 X-Spam-Level: X-Spam-Status: No, score=-8.202 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 x63uVa6YOehX for ; Mon, 6 Feb 2012 20:49:26 -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 3393C11E8094 for ; Mon, 6 Feb 2012 20:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=10281; q=dns/txt; s=iport; t=1328590166; x=1329799766; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=BlJkch+OPhJVhgmUH7vGPL5Y4KcPjkfdwJHVUtW2MTQ=; b=b5+Ldy9Q3A6vpv5VjSbSMxdyBl1KDRu/9VZwRBhxyEOv2XMHwOXHt8Um jI6EoyWkMtbVHKaY3fDXovKLMYIwaBnSWXmntti5UPDJt4f1hjPBzBgu+ mUNWaYVKc7Q8XLUam6REhpbzU23n+1xgL4w1owmoOw5DHufsggywoRTN2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAButME+tJXG8/2dsb2JhbAA4BwOCTawTZ4EFgXIBAQEDAQEBAQ8BKhgRCAsSAQgRAwECUAYoCAEBBAENBSKHWgmZUgGfC4gVS4J4EwEIBQMDCQcBBwcCg1E2BSE3gyEEiBEzjGSLCodv X-IronPort-AV: E=Sophos;i="4.73,374,1325462400"; d="scan'208,217";a="56860388" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 07 Feb 2012 04:49:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q174nMl2018839; Tue, 7 Feb 2012 04:49:22 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 22:49:22 -0600 Received: from 10.86.255.42 ([10.86.255.42]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Feb 2012 04:49:22 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 06 Feb 2012 23:49:49 -0500 From: Kamran Raza To: Lizhong Jin , , , Message-ID: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlU+vrnSqQEu4oc0qYFtfJC+trqQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3411416989_5024916" X-OriginalArrivalTime: 07 Feb 2012 04:49:22.0457 (UTC) FILETIME=[DC18F090:01CCE553] 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: Tue, 07 Feb 2012 04:49:29 -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_3411416989_5024916 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Lizhong, Using single adj [ and just checking local interface enabling for given AF = + capabilities ] will not suffice/work because: 1. LDP capabilities are advertised on peer/session level and do not correspond to adj capabilities. 2. An LSR must not be forwarding MPLS on an interface unless/until it has got an MPLS adj on it =AD extending the same to address families, an LSR must not forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [ Single adj will not convey us remote node=B9s interface capability for given AF, and it will be incorrect to forward 6 MPLS labelled traffic on it unles= s we know that remote intf is v6 MPLS enabled ] My 2 cents. -- Kamran On 12-02-06 10:22 PM, "Lizhong Jin" wrote: >=20 > Hi,=20 > I wonder if it is feasible to use LDP capability to advertise IPv6 FEC wi= thout > IPv6 adjacency, and only use one adjacency for LDP session in dual-stack > network. LDP capability is per node capability, not per interface capabil= ity. > 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 > [Kamran]: >=20 > However, IMO, it is valuable to allow two independent LDP sessions for IP= v4 > 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 IP= V6. >> > 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 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d are > not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d > 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. >=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_3411416989_5024916 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong,

Using single adj [ and just checking local interface enabling for given AF = + capabilities ] will not suffice/work because:

 1. LDP capabilities are advertised on peer/session level and do not c= orrespond to adj capabilities.
 2. An LSR must not be forwarding MPLS on an interface unless/until it= has got an MPLS adj on it – extending the same to address families, a= n LSR must not forward MPLS v6 on an interface unless it has got MPLS v6 adj= on it. [ Single adj will not convey us remote node’s interface capabi= lity for given AF, and it will be incorrect to forward 6 MPLS labelled traff= ic on it unless we know that remote intf is v6 MPLS enabled ]

 My 2 cents.
-- Kamran

On 12-02-06 10:22 PM, "Lizhong Jin" <lizhong.jin@zte.com.cn> wrote:

<= SPAN STYLE=3D'font-size:11pt'>
Hi,
I wonder if it is feasible to use LDP capability to advertise IPv6 FEC with= out IPv6 adjacency, and only use one adjacency for LDP session in dual-stack= network. LDP capability is per node capability, not per interface capabilit= y. 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 o= r not. The link adjacency could be used to assist such kind of checking.
[Kamran]:

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 n= eed new LDP version number to identify IPv6 LSR-ID. Or we use different 32bi= t 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@g= mail.com>
> Cc: "Aissaoui, Mustapha \(Mustapha\)"
>    <m= ustapha.aissaoui@alcatel-lucent.com>,  "mpls@ietf.org"
>    <mpls@ietf.org> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> Message-ID:
>    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHM= BSA3.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 IP= V6.
> 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 im= pacts.
>
> Thanks,
> Pranjal
>

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is con= fidential. 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. I= f 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 sen= der.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

___________= ____________________________________
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_3411416989_5024916-- From lizhong.jin@zte.com.cn Mon Feb 6 21:47: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 3B83B21F856A for ; Mon, 6 Feb 2012 21:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.57 X-Spam-Level: X-Spam-Status: No, score=-100.57 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5GCYyz5KRnmH for ; Mon, 6 Feb 2012 21:47:50 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 723F621F848C for ; Mon, 6 Feb 2012 21:47:49 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690806486374; Tue, 7 Feb 2012 13:20:41 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 83373.6407659339; Tue, 7 Feb 2012 13:47:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q175lWII087542; Tue, 7 Feb 2012 13:47:32 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Kamran Raza MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 7 Feb 2012 13:46:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-07 13:47:34, Serialize complete at 2012-02-07 13:47:34 Content-Type: multipart/alternative; boundary="=_alternative 001FD21D4825799D_=" X-MAIL: mse02.zte.com.cn q175lWII087542 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 05:47:51 -0000 This is a multipart message in MIME format. --=_alternative 001FD21D4825799D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgS2FtcmFuLA0KSSBBZ3JlZS4gQW5kIGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0wNiBzZWN0 aW9uIDcgc2F5czogIEFub3RoZXIgc29sdXRpb24gDQpmb3IgZ2V0dGluZyB0aGUgc2FtZSByZXN1 bHQgYXMgYWJvdmUgaXMgYnkgbmVnb3RpYXRpbmcgdGhlIElQIENhcGFiaWxpdHkgDQpmb3IgYSBn aXZlbiBBRkksIGFzIHNwZWNpZmllZCBpbiBbSVBQV0NhcF0uIFN1Y2ggd29yZGluZyBpcyBpbmNv cnJlY3QsIA0KYmVjYXVzZSB0aGUgcmVzdWx0IG9mIElQdjQgYW5kIElQdjYgSGVsbG8gQWRqYWNl bmNpZXMgYW5kIElQIENhcGFiaWxpdHkgDQpmb3IgYSBnaXZlbiBBRkkgaXMgZGlmZmVyZW50LiBJ UHY2IEhlbGxvIEFkamFjZW5jaWVzIGNvdWxkIG5vdCBiZSByZXBsYWNlZCANCmJ5IExEUCBJUCBD YXBhYmlsaXR5Lg0KDQpUaGFua3MNCkxpemhvbmcNCiANCg0KS2FtcmFuIFJhemEgPHNrcmF6YUBj aXNjby5jb20+IHdyb3RlIDIwMTIvMDIvMDcgMTI6NDk6NDk6DQoNCj4gSGkgTGl6aG9uZywNCj4g DQo+IFVzaW5nIHNpbmdsZSBhZGogWyBhbmQganVzdCBjaGVja2luZyBsb2NhbCBpbnRlcmZhY2Ug ZW5hYmxpbmcgZm9yIA0KPiBnaXZlbiBBRiArIGNhcGFiaWxpdGllcyBdIHdpbGwgbm90IHN1ZmZp Y2Uvd29yayBiZWNhdXNlOg0KPiANCj4gIDEuIExEUCBjYXBhYmlsaXRpZXMgYXJlIGFkdmVydGlz ZWQgb24gcGVlci9zZXNzaW9uIGxldmVsIGFuZCBkbyBub3QNCj4gY29ycmVzcG9uZCB0byBhZGog Y2FwYWJpbGl0aWVzLg0KPiAgMi4gQW4gTFNSIG11c3Qgbm90IGJlIGZvcndhcmRpbmcgTVBMUyBv biBhbiBpbnRlcmZhY2UgdW5sZXNzL3VudGlsIA0KPiBpdCBoYXMgZ290IGFuIE1QTFMgYWRqIG9u IGl0IKhDIGV4dGVuZGluZyB0aGUgc2FtZSB0byBhZGRyZXNzIA0KPiBmYW1pbGllcywgYW4gTFNS IG11c3Qgbm90IGZvcndhcmQgTVBMUyB2NiBvbiBhbiBpbnRlcmZhY2UgdW5sZXNzIGl0IA0KPiBo YXMgZ290IE1QTFMgdjYgYWRqIG9uIGl0LiBbIFNpbmdsZSBhZGogd2lsbCBub3QgY29udmV5IHVz IHJlbW90ZSANCj4gbm9kZaGvcyBpbnRlcmZhY2UgY2FwYWJpbGl0eSBmb3IgZ2l2ZW4gQUYsIGFu ZCBpdCB3aWxsIGJlIGluY29ycmVjdCANCj4gdG8gZm9yd2FyZCA2IE1QTFMgbGFiZWxsZWQgdHJh ZmZpYyBvbiBpdCB1bmxlc3Mgd2Uga25vdyB0aGF0IHJlbW90ZSANCj4gaW50ZiBpcyB2NiBNUExT IGVuYWJsZWQgXQ0KPiANCj4gIE15IDIgY2VudHMuDQo+IC0tIEthbXJhbg0KPiANCj4gT24gMTIt MDItMDYgMTA6MjIgUE0sICJMaXpob25nIEppbiIgPGxpemhvbmcuamluQHp0ZS5jb20uY24+IHdy b3RlOg0KDQo+IA0KPiBIaSwgDQo+IEkgd29uZGVyIGlmIGl0IGlzIGZlYXNpYmxlIHRvIHVzZSBM RFAgY2FwYWJpbGl0eSB0byBhZHZlcnRpc2UgSVB2NiANCj4gRkVDIHdpdGhvdXQgSVB2NiBhZGph Y2VuY3ksIGFuZCBvbmx5IHVzZSBvbmUgYWRqYWNlbmN5IGZvciBMRFAgDQo+IHNlc3Npb24gaW4g ZHVhbC1zdGFjayBuZXR3b3JrLiBMRFAgY2FwYWJpbGl0eSBpcyBwZXIgbm9kZSANCj4gY2FwYWJp bGl0eSwgbm90IHBlciBpbnRlcmZhY2UgY2FwYWJpbGl0eS4gQnV0IGZvciBMRFAgdG8gY2hvb3Nl IHRoZSANCj4gY29ycmVjdCBkb3duc3RyZWFtIHNlc3Npb24gYW5kIG91dHB1dCBpbnRlcmZhY2Ug Zm9yIGVhY2ggRkVDLCBpdCANCj4gc2hvdWxkIGFsc28gY2hlY2sgaWYgdGhlIG91dHB1dCBpbnRl cmZhY2UgaXMgTERQIGVuYWJsZWQgb3Igbm90LiBUaGUNCj4gbGluayBhZGphY2VuY3kgY291bGQg YmUgdXNlZCB0byBhc3Npc3Qgc3VjaCBraW5kIG9mIGNoZWNraW5nLiANCj4gDQo+IFtLYW1yYW5d Og0KPiANCj4gSG93ZXZlciwgSU1PLCBpdCBpcyB2YWx1YWJsZSB0byBhbGxvdyB0d28gaW5kZXBl bmRlbnQgTERQIHNlc3Npb25zIA0KPiBmb3IgSVB2NCBhbmQgSVB2NiBhcyBhbiBvcHRpb24uIFJl Z2FyZGluZyB0aGUgZm9ybWF0IGRlZmluaXRpb24gaW4gDQo+IFJGQzUwMzYsIHdlIG1heSBuZWVk IG5ldyBMRFAgdmVyc2lvbiBudW1iZXIgdG8gaWRlbnRpZnkgSVB2NiBMU1ItSUQuDQo+IE9yIHdl IHVzZSBkaWZmZXJlbnQgMzJiaXQgTFNSLUlEIGZvciBJUHY2IHdpdGggSVB2NCwgYnV0IEkgcHJl ZmVyIA0KPiBuZXcgZm9ybWF0IG9mIExTUi1JRC4gDQo+IA0KPiBSZWdhcmRzIA0KPiBMaXpob25n IA0KPiANCj4gDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IA0KPiA+IE1lc3NhZ2U6IDENCj4gPiBE YXRlOiBUdWUsIDcgRmViIDIwMTIgMDU6Mjg6MjEgKzA1MzANCj4gPiBGcm9tOiAiRHV0dGEsIFBy YW5qYWwgSyAoUHJhbmphbCkiIDxwcmFuamFsLmR1dHRhQGFsY2F0ZWwtbHVjZW50LmNvbT4NCj4g PiBUbzogVmlzaHdhcyBNYW5yYWwgPHZpc2h3YXMuaWV0ZkBnbWFpbC5jb20+DQo+ID4gQ2M6ICJB aXNzYW91aSwgTXVzdGFwaGEgXChNdXN0YXBoYVwpIg0KPiA+ICAgIDxtdXN0YXBoYS5haXNzYW91 aUBhbGNhdGVsLWx1Y2VudC5jb20+LCAgIm1wbHNAaWV0Zi5vcmciDQo+ID4gICAgPG1wbHNAaWV0 Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1w bHMtbGRwLWlwdjYtMDYNCj4gPiBNZXNzYWdlLUlEOg0KPiA+ICAgIDxDNTg0MDQ2NDY2RUQyMjRD QTkyQzFCQzMzMTNCOTYzRTA5RUZFOEQ2NjdASU5CQU5TWENITUJTQTMuaW4uDQo+ID4gYWxjYXRl bC1sdWNlbnQuY29tPg0KPiA+IA0KPiA+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl dD0idXMtYXNjaWkiDQo+ID4gDQo+ID4gSSB3b3VsZCByYXRoZXIgZm9yIGNvbXBsZXRlIHNlcGFy YXRpb24gd2l0aCBtdWx0aXBsZSBsc3ItaWQgYmVjYXVzZSANCj4gPiBoYXZpbmcgc2VwYXJhdGUg bGluayBhZGphY2VuY2llcyBkb2VzIG5vdCByZWFsbHkgc29sdmVkIGFueSBwcm9ibGVtLg0KPiA+ IFNpbmNlIGhlbGxvIGFkamFjZW5jaWVzIGFyZSBhc3NvY2lhdGVkIHdpdGggYSBsaW5rLCBzdGls bCBmYXRlIA0KPiA+IHNoYXJpbmcgd291bGQgY29udGludWUgb3ZlciB0aGUgc2luZ2xlIGxkcC90 Y3Agc2Vzc2lvbiBmb3IgSVBWNCBhbmQgDQpJUFY2Lg0KPiA+IEhhdmluZyBJUFY0IGFuZCBJUFY2 IHNwZWNpZmljIGhlbGxvIGFkamFjZW5jaWVzIG92ZXIgYSBsaW5rIHdvdWxkIA0KPiA+IG9ubHkg ZGVjaWRlIHdoZXRoZXIgc3VjaCBhIGxpbmsgaXMgdG8gYmUgcHJvZ3JhbW1lZCBmb3IgSVBWNCBv ciBJUFY2DQo+ID4gZWdyZXNzIHRyYWZmaWMgYnV0IEkgc2VlIGl0IGFzIG92ZXJraWxsIGFuZCB1 bm5lY2Vzc2FyeSBzY2FsYWJpbGl0eSANCmltcGFjdHMuDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+ IFByYW5qYWwNCj4gPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IA0KPiAtLSANCj4gU3ll ZCBLYW1yYW4gUmF6YQ0KPiBUZWNobmljYWwgTGVhZGVyLCBTUFJTRyBJT1MtWFIgUm91dGluZyAo TVBMUykNCj4gQ2lzY28gU3lzdGVtcywgSW5jLiwgDQo+IEthbmF0YSwgT04sIEsySyAzRTgsIENh bmFkYSANCj4gUGg6ICsxICg2MTMpIDI1NC00NTIwDQo+IGh0dHA6Ly93d3cuY2lzY28uY29tIA0K PiANCj4gDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVu dGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNl Y3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0 aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRy YW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFk ZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ug bm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhp cyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFu dGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 001FD21D4825799D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEthbXJhbiw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgQWdyZWUuIEFuZCBkcmFmdC1pZXRm LW1wbHMtbGRwLWlwdjYtMDYNCnNlY3Rpb24gNyBzYXlzOiAmbmJzcDtBbm90aGVyIHNvbHV0aW9u IGZvciBnZXR0aW5nIHRoZSBzYW1lIHJlc3VsdCBhcyBhYm92ZQ0KaXMgYnkgbmVnb3RpYXRpbmcg dGhlIElQIENhcGFiaWxpdHkgZm9yIGEgZ2l2ZW4gQUZJLCBhcyBzcGVjaWZpZWQgaW4gW0lQUFdD YXBdLg0KU3VjaCB3b3JkaW5nIGlzIGluY29ycmVjdCwgYmVjYXVzZSB0aGUgcmVzdWx0IG9mIElQ djQgYW5kIElQdjYgSGVsbG8gQWRqYWNlbmNpZXMNCmFuZCBJUCBDYXBhYmlsaXR5IGZvciBhIGdp dmVuIEFGSSBpcyBkaWZmZXJlbnQuIElQdjYgSGVsbG8gQWRqYWNlbmNpZXMNCmNvdWxkIG5vdCBi ZSByZXBsYWNlZCBieSBMRFAgSVAgQ2FwYWJpbGl0eS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+TGl6aG9uZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0i QXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkthbXJhbiBS YXphICZsdDtza3JhemFAY2lzY28uY29tJmd0OyB3cm90ZSAyMDEyLzAyLzA3DQoxMjo0OTo0OTo8 YnI+DQo8YnI+DQomZ3Q7IEhpIExpemhvbmcsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFVzaW5nIHNp bmdsZSBhZGogWyBhbmQganVzdCBjaGVja2luZyBsb2NhbCBpbnRlcmZhY2UgZW5hYmxpbmcgZm9y DQo8YnI+DQomZ3Q7IGdpdmVuIEFGICsgY2FwYWJpbGl0aWVzIF0gd2lsbCBub3Qgc3VmZmljZS93 b3JrIGJlY2F1c2U6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOzEuIExEUCBjYXBhYmlsaXRp ZXMgYXJlIGFkdmVydGlzZWQgb24gcGVlci9zZXNzaW9uIGxldmVsIGFuZA0KZG8gbm90PGJyPg0K Jmd0OyBjb3JyZXNwb25kIHRvIGFkaiBjYXBhYmlsaXRpZXMuPGJyPg0KJmd0OyAmbmJzcDsyLiBB biBMU1IgbXVzdCBub3QgYmUgZm9yd2FyZGluZyBNUExTIG9uIGFuIGludGVyZmFjZSB1bmxlc3Mv dW50aWwNCjxicj4NCiZndDsgaXQgaGFzIGdvdCBhbiBNUExTIGFkaiBvbiBpdCCoQyBleHRlbmRp bmcgdGhlIHNhbWUgdG8gYWRkcmVzcyA8YnI+DQomZ3Q7IGZhbWlsaWVzLCBhbiBMU1IgbXVzdCBu b3QgZm9yd2FyZCBNUExTIHY2IG9uIGFuIGludGVyZmFjZSB1bmxlc3MgaXQNCjxicj4NCiZndDsg aGFzIGdvdCBNUExTIHY2IGFkaiBvbiBpdC4gWyBTaW5nbGUgYWRqIHdpbGwgbm90IGNvbnZleSB1 cyByZW1vdGUNCjxicj4NCiZndDsgbm9kZaGvcyBpbnRlcmZhY2UgY2FwYWJpbGl0eSBmb3IgZ2l2 ZW4gQUYsIGFuZCBpdCB3aWxsIGJlIGluY29ycmVjdA0KPGJyPg0KJmd0OyB0byBmb3J3YXJkIDYg TVBMUyBsYWJlbGxlZCB0cmFmZmljIG9uIGl0IHVubGVzcyB3ZSBrbm93IHRoYXQgcmVtb3RlDQo8 YnI+DQomZ3Q7IGludGYgaXMgdjYgTVBMUyBlbmFibGVkIF08YnI+DQomZ3Q7IDxicj4NCiZndDsg Jm5ic3A7TXkgMiBjZW50cy48YnI+DQomZ3Q7IC0tIEthbXJhbjxicj4NCiZndDsgPGJyPg0KJmd0 OyBPbiAxMi0wMi0wNiAxMDoyMiBQTSwgJnF1b3Q7TGl6aG9uZyBKaW4mcXVvdDsgJmx0O2xpemhv bmcuamluQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBIaSwgPGJyPg0KJmd0OyBJIHdvbmRlciBpZiBp dCBpcyBmZWFzaWJsZSB0byB1c2UgTERQIGNhcGFiaWxpdHkgdG8gYWR2ZXJ0aXNlIElQdjYNCjxi cj4NCiZndDsgRkVDIHdpdGhvdXQgSVB2NiBhZGphY2VuY3ksIGFuZCBvbmx5IHVzZSBvbmUgYWRq YWNlbmN5IGZvciBMRFAgPGJyPg0KJmd0OyBzZXNzaW9uIGluIGR1YWwtc3RhY2sgbmV0d29yay4g TERQIGNhcGFiaWxpdHkgaXMgcGVyIG5vZGUgPGJyPg0KJmd0OyBjYXBhYmlsaXR5LCBub3QgcGVy IGludGVyZmFjZSBjYXBhYmlsaXR5LiBCdXQgZm9yIExEUCB0byBjaG9vc2UgdGhlDQo8YnI+DQom Z3Q7IGNvcnJlY3QgZG93bnN0cmVhbSBzZXNzaW9uIGFuZCBvdXRwdXQgaW50ZXJmYWNlIGZvciBl YWNoIEZFQywgaXQgPGJyPg0KJmd0OyBzaG91bGQgYWxzbyBjaGVjayBpZiB0aGUgb3V0cHV0IGlu dGVyZmFjZSBpcyBMRFAgZW5hYmxlZCBvciBub3QuIFRoZTxicj4NCiZndDsgbGluayBhZGphY2Vu Y3kgY291bGQgYmUgdXNlZCB0byBhc3Npc3Qgc3VjaCBraW5kIG9mIGNoZWNraW5nLiA8YnI+DQom Z3Q7IDxicj4NCiZndDsgW0thbXJhbl06PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhvd2V2ZXIsIElN TywgaXQgaXMgdmFsdWFibGUgdG8gYWxsb3cgdHdvIGluZGVwZW5kZW50IExEUCBzZXNzaW9ucw0K PGJyPg0KJmd0OyBmb3IgSVB2NCBhbmQgSVB2NiBhcyBhbiBvcHRpb24uIFJlZ2FyZGluZyB0aGUg Zm9ybWF0IGRlZmluaXRpb24gaW4NCjxicj4NCiZndDsgUkZDNTAzNiwgd2UgbWF5IG5lZWQgbmV3 IExEUCB2ZXJzaW9uIG51bWJlciB0byBpZGVudGlmeSBJUHY2IExTUi1JRC48YnI+DQomZ3Q7IE9y IHdlIHVzZSBkaWZmZXJlbnQgMzJiaXQgTFNSLUlEIGZvciBJUHY2IHdpdGggSVB2NCwgYnV0IEkg cHJlZmVyDQo8YnI+DQomZ3Q7IG5ldyBmb3JtYXQgb2YgTFNSLUlELiA8YnI+DQomZ3Q7IDxicj4N CiZndDsgUmVnYXJkcyA8YnI+DQomZ3Q7IExpemhvbmcgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBNZXNzYWdlOiAxPGJyPg0KJmd0OyAmZ3Q7IERhdGU6IFR1ZSwgNyBGZWIgMjAxMiAwNToyODoy MSArMDUzMDxicj4NCiZndDsgJmd0OyBGcm9tOiAmcXVvdDtEdXR0YSwgUHJhbmphbCBLIChQcmFu amFsKSZxdW90OyAmbHQ7cHJhbmphbC5kdXR0YUBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFRvOiBWaXNod2FzIE1hbnJhbCAmbHQ7dmlzaHdhcy5pZXRmQGdtYWlsLmNvbSZn dDs8YnI+DQomZ3Q7ICZndDsgQ2M6ICZxdW90O0Fpc3Nhb3VpLCBNdXN0YXBoYSBcKE11c3RhcGhh XCkmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyZsdDttdXN0YXBoYS5haXNzYW91 aUBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7LCAmbmJzcDsmcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQom Z3Q7ICZndDsgU3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1wbHMt bGRwLWlwdjYtMDY8YnI+DQomZ3Q7ICZndDsgTWVzc2FnZS1JRDo8YnI+DQomZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyZsdDtDNTg0MDQ2NDY2RUQyMjRDQTkyQzFCQzMzMTNCOTYzRTA5RUZFOEQ2NjdA SU5CQU5TWENITUJTQTMuaW4uPGJyPg0KJmd0OyAmZ3Q7IGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgJmd0OyBDb250ZW50LVR5cGU6 IHRleHQvcGxhaW47IGNoYXJzZXQ9JnF1b3Q7dXMtYXNjaWkmcXVvdDs8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IEkgd291bGQgcmF0aGVyIGZvciBjb21wbGV0ZSBzZXBhcmF0aW9uIHdp dGggbXVsdGlwbGUgbHNyLWlkIGJlY2F1c2UNCjxicj4NCiZndDsgJmd0OyBoYXZpbmcgc2VwYXJh dGUgbGluayBhZGphY2VuY2llcyBkb2VzIG5vdCByZWFsbHkgc29sdmVkIGFueSBwcm9ibGVtLjxi cj4NCiZndDsgJmd0OyBTaW5jZSBoZWxsbyBhZGphY2VuY2llcyBhcmUgYXNzb2NpYXRlZCB3aXRo IGEgbGluaywgc3RpbGwgZmF0ZQ0KPGJyPg0KJmd0OyAmZ3Q7IHNoYXJpbmcgd291bGQgY29udGlu dWUgb3ZlciB0aGUgc2luZ2xlIGxkcC90Y3Agc2Vzc2lvbiBmb3IgSVBWNA0KYW5kIElQVjYuPGJy Pg0KJmd0OyAmZ3Q7IEhhdmluZyBJUFY0IGFuZCBJUFY2IHNwZWNpZmljIGhlbGxvIGFkamFjZW5j aWVzIG92ZXIgYSBsaW5rIHdvdWxkDQo8YnI+DQomZ3Q7ICZndDsgb25seSBkZWNpZGUgd2hldGhl ciBzdWNoIGEgbGluayBpcyB0byBiZSBwcm9ncmFtbWVkIGZvciBJUFY0DQpvciBJUFY2PGJyPg0K Jmd0OyAmZ3Q7IGVncmVzcyB0cmFmZmljIGJ1dCBJIHNlZSBpdCBhcyBvdmVya2lsbCBhbmQgdW5u ZWNlc3Nhcnkgc2NhbGFiaWxpdHkNCmltcGFjdHMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7IFByYW5qYWw8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBtcGxzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgbXBsc0BpZXRmLm9y Zzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC90 dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0K Jmd0OyBTeWVkIEthbXJhbiBSYXphPGJyPg0KJmd0OyBUZWNobmljYWwgTGVhZGVyLCBTUFJTRyBJ T1MtWFIgUm91dGluZyAoTVBMUyk8YnI+DQomZ3Q7IENpc2NvIFN5c3RlbXMsIEluYy4sIDxicj4N CiZndDsgS2FuYXRhLCBPTiwgSzJLIDNFOCwgQ2FuYWRhIDxicj4NCiZndDsgUGg6ICsxICg2MTMp IDI1NC00NTIwPGJyPg0KJmd0OyBodHRwOi8vd3d3LmNpc2NvLmNvbSA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlv biZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5i c3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29s ZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3Jn YW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lz Jm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3Zl Jm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3Jl Y3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNw O2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDth bmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0 Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtz b2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu ZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkm bmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7 cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxl YXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7 aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5k Jm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0K PC9wcmU+ --=_alternative 001FD21D4825799D_=-- From mustapha.aissaoui@alcatel-lucent.com Tue Feb 7 07:03: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 99DF421F87C7 for ; Tue, 7 Feb 2012 07:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.182 X-Spam-Level: X-Spam-Status: No, score=-7.182 tagged_above=-999 required=5 tests=[AWL=-0.584, 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 BTc+KCkwOPen for ; Tue, 7 Feb 2012 07:03:21 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 353D721F8653 for ; Tue, 7 Feb 2012 07:03:18 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q17F3A6V014609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2012 09:03:10 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q17F3AdH011928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Feb 2012 09:03:10 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 7 Feb 2012 09:03:09 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: Kamran Raza , Lizhong Jin , "Dutta, Pranjal K (Pranjal)" , "vishwas.ietf@gmail.com" Date: Tue, 7 Feb 2012 09:03:09 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlU+vrnSqQEu4oc0qYFtfJC+trqQAUqv8A Message-ID: <5DF53972F7E9134782DCE51624466FE50AD55FDAD3@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_5DF53972F7E9134782DCE51624466FE50AD55FDAD3USNAVSXCHMBSC_" 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.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: Tue, 07 Feb 2012 15:03:22 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD55FDAD3USNAVSXCHMBSC_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kamran, in LDP, the ability to advertise a FEC type between peers is independent of= the adjacency established. I am not sure why this was not an issue for oth= er FEC types (unicast IPv4 FEC, PW FEC, mLDP p2mp FEC) and it is now for un= icast IPv6 FEC prefixes. The user controls which prefix type to advertize/a= ccept to/from a peer via import/export policies and LDP node capability adv= ertisement. You point 2 below is about FEC resolution and not FEC advertisement. When y= ou resolve a FEC, you need to check which LSR-id owns the next-hop in the r= outing table for the IPv6 prefix and this is provided by the list of interf= ace addresses in the Address List TLV. If you have received a label for the= FEC from the LSR-id which owns the IPv6 next-hop, you can resolve the FEC = to that interface even if the Hello adjacency over that interface is IPv4 o= nly. We need to keep that separation between FEC advertisement and adjacency typ= e for backward compatibility with RFC 5036. What we need in my view is to r= elax RFC 5036 to allow the setup of multiple LDP adjacencies/sessions betwe= en two LSRs which use two different LSR-id but the same global label-space-= id. This can be done with some rules to avoid loops. Users will then be fre= e to dedicate an LDP session for IPv6 prefixes and another for IPv4 prefixe= s much like the BGP model allows for. Regards, Mustapha. ________________________________ From: Kamran Raza [mailto:skraza@cisco.com] Sent: Monday, February 06, 2012 11:50 PM To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissao= ui, Mustapha (Mustapha) Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong, Using single adj [ and just checking local interface enabling for given AF = + capabilities ] will not suffice/work because: 1. LDP capabilities are advertised on peer/session level and do not corres= pond to adj capabilities. 2. An LSR must not be forwarding MPLS on an interface unless/until it has = got an MPLS adj on it =96 extending the same to address families, an LSR mu= st not forward MPLS v6 on an interface unless it has got MPLS v6 adj on it.= [ Single adj will not convey us remote node=92s interface capability for g= iven AF, and it will be incorrect to forward 6 MPLS labelled traffic on it = unless we know that remote intf is v6 MPLS enabled ] My 2 cents. -- Kamran On 12-02-06 10:22 PM, "Lizhong Jin" wrote: Hi, I wonder if it is feasible to use LDP capability to advertise IPv6 FEC with= out IPv6 adjacency, and only use one adjacency for LDP session in dual-stac= k network. LDP capability is per node capability, not per interface capabil= ity. But for LDP to choose the correct downstream session and output interf= ace for each FEC, it should also check if the output interface is LDP enabl= ed or not. The link adjacency could be used to assist such kind of checking= . [Kamran]: 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 32= bit 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 impac= ts. > > Thanks, > Pranjal > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e 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 th= e 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 --_000_5DF53972F7E9134782DCE51624466FE50AD55FDAD3USNAVSXCHMBSC_ 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=3D389364114-07022012><FONT size=3D2= =20 face=3DArial>Kamran,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D389364114-07022012><FONT size=3D2= =20 face=3DArial>in LDP, the ability to advertise a FEC type between peers= is=20 independent of the adjacency established. I am not sure why this was not an= =20 issue for other FEC types (unicast IPv4 FEC, PW FEC, mLDP p2mp FEC) and it = is=20 now for unicast IPv6 FEC prefixes. The user controls which prefix type to=20 advertize/accept to/from a peer via import/export policies and LDP node=20 capability advertisement.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D389364114-07022012><FONT size=3D2= =20 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D389364114-07022012><FONT size=3D2= =20 face=3DArial>You point 2 below is about FEC resolution and not FE= C=20 advertisement. When you resolve a FEC, you need to check which LSR-id owns = the=20 next-hop in the routing table for the IPv6 prefix and this is provided by t= he=20 list of interface addresses in the Address List TLV. If you have received a= =20 label for the FEC from the LSR-id which owns the IPv6 next-hop, you can res= olve=20 the FEC to that interface even if the Hello adjacency over that interface i= s=20 IPv4 only. </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D389364114-07022012><FONT size=3D2= =20 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D389364114-07022012></SPAN><SPAN class=3D389364114-07022012>We need = to keep=20 that separation between FEC advertisement and adjacency type for backw= ard=20 compatibility with RFC 5036. What we need in my view is to relax RFC 5036 t= o=20 allow the setup of multiple LDP adjacencies/sessions between two LSRs which= use=20 two different LSR-id but the same global label-space-id. This can be done w= ith=20 some rules to avoid loops. Users will then be free to dedicate an LDP sessi= on=20 for IPv6 prefixes and another for IPv4 prefixes much like the BGP model all= ows=20 for.</SPAN></FONT></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20 class=3D389364114-07022012></SPAN></FONT></FONT><FONT face=3DArial><FONT=20 size=3D2><SPAN class=3D389364114-07022012></SPAN></FONT></FONT><FONT=20 face=3DArial><FONT size=3D2><SPAN=20 class=3D389364114-07022012></SPAN></FONT></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D389364114-07022012><FONT size=3D2= =20 face=3DArial>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D389364114-07022012><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> Monday, February 06, 2012 11:50 PM<BR><B>To:</B> Lizhong J= in;=20 Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, Mustapha=20 (Mustapha)<BR><B>Cc:</B> mpls@ietf.org<BR><B>Subject:</B> Re: [mpls] Commen= ts 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">Hi Lizhong,<BR><BR>Using single adj [ and just ch= ecking=20 local interface enabling for given AF + capabilities ] will not suffice/wor= k=20 because:<BR><BR> 1. LDP capabilities are advertised on peer/session le= vel=20 and do not correspond to adj capabilities.<BR> 2. An LSR must not be=20 forwarding MPLS on an interface unless/until it has got an MPLS adj on it = =96=20 extending the same to address families, an LSR must not forward MPLS v6 on = an=20 interface unless it has got MPLS v6 adj on it. [ Single adj will not convey= us=20 remote node=92s interface capability for given AF, and it will be incorrect= to=20 forward 6 MPLS labelled traffic on it unless we know that remote intf is v6= MPLS=20 enabled ]<BR><BR> My 2 cents.<BR>-- Kamran<BR><BR>On 12-02-06 10:22 PM= ,=20 "Lizhong Jin" <<A=20 href=3D"lizhong.jin@zte.com.cn">lizhong.jin@zte.com.cn</A>>=20 wrote:<BR><BR></SPAN></FONT> <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 11pt"><BR>Hi, <BR>I wonder if it is feasible to use L= DP=20 capability to advertise IPv6 FEC without IPv6 adjacency, and only use one= =20 adjacency for LDP session in dual-stack network. LDP capability is per no= de=20 capability, not per interface capability. But for LDP to choose the corre= ct=20 downstream session and output interface for each FEC, it should also chec= k if=20 the output interface is LDP enabled or not. The link adjacency could be u= sed=20 to assist such kind of checking. <BR><BR>[Kamran]:<BR><BR>However, IMO, i= t is=20 valuable to allow two independent LDP sessions for IPv4 and IPv6 as an op= tion.=20 Regarding the format definition in RFC5036, we may need new LDP version n= umber=20 to identify IPv6 LSR-ID. Or we use different 32bit LSR-ID for IPv6 with I= Pv4,=20 but I prefer new format of LSR-ID. <BR><BR>Regards <BR>Lizhong=20 <BR><BR><BR>>=20 ----------------------------------------------------------------------<BR= >>=20 <BR>> Message: 1<BR>> Date: Tue, 7 Feb 2012 05:28:21 +0530<BR>> = From:=20 "Dutta, Pranjal K (Pranjal)" <<A=20 href=3D"pranjal.dutta@alcatel-lucent.com">pranjal.dutta@alcatel-lucent.co= m</A>><BR>>=20 To: Vishwas Manral <<A=20 href=3D"vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</A>><BR>> Cc= :=20 "Aissaoui, Mustapha \(Mustapha\)"<BR>>    <<A=20 href=3D"mustapha.aissaoui@alcatel-lucent.com">mustapha.aissaoui@alcatel-l= ucent.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">C58= 4046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in</A>.<BR>>=20 alcatel-lucent.com><BR>>    <BR>> Content-Type:=20 text/plain; charset=3D"us-ascii"<BR>> <BR>> I would rather for comp= lete=20 separation with multiple lsr-id because <BR>> having separate link=20 adjacencies does not really solved any problem.<BR>> Since hello=20 adjacencies are associated with a link, still fate <BR>> sharing would= =20 continue over the single ldp/tcp session for IPV4 and IPV6.<BR>> Havin= g=20 IPV4 and IPV6 specific hello adjacencies over a link would <BR>> only= =20 decide whether such a link is to be programmed for IPV4 or IPV6<BR>> e= gress=20 traffic but I see it as overkill and unnecessary scalability impacts.<BR>= >=20 <BR>> Thanks,<BR>> Pranjal<BR>>=20 <BR><BR>--------------------------------------------------------<BR>ZTE=20 Information Security Notice: The information contained in this mail is so= lely=20 property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy an= d are=20 not permitted to disclose the contents of this communication to=20 others.<BR>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= =20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are those = of=20 the individual sender.<BR>This message has been scanned for viruses and S= pam=20 by ZTE Anti-Spam system.<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_5DF53972F7E9134782DCE51624466FE50AD55FDAD3USNAVSXCHMBSC_-- From mustapha.aissaoui@alcatel-lucent.com Tue Feb 7 07:12:03 2012 Return-Path: <mustapha.aissaoui@alcatel-lucent.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 B77A021F8810 for <mpls@ietfa.amsl.com>; Tue, 7 Feb 2012 07:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.036 X-Spam-Level: X-Spam-Status: No, score=-7.036 tagged_above=-999 required=5 tests=[AWL=-0.438, 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 rE4H5F2Ax6Ex for <mpls@ietfa.amsl.com>; Tue, 7 Feb 2012 07:12:02 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFFB21F87E6 for <mpls@ietf.org>; Tue, 7 Feb 2012 07:12:02 -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 q17FBsJH009833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2012 09:11:54 -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 q17FBsSg010496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Feb 2012 09:11:54 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 7 Feb 2012 09:11:53 -0600 From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> To: Lizhong Jin <lizhong.jin@zte.com.cn>, "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>, "vishwas.ietf@gmail.com" <vishwas.ietf@gmail.com> Date: Tue, 7 Feb 2012 09:11:52 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlR+hW13amK3+CRWyR54u0xbDYrAAYcWrg Message-ID: <5DF53972F7E9134782DCE51624466FE50AD55FDAD9@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <mailman.5367.1328572725.3200.mpls@ietf.org> <OFA7A7CD93.8FCD9D27-ON4825799D.000E06C3-4825799D.0012A0F1@zte.com.cn> In-Reply-To: <OFA7A7CD93.8FCD9D27-ON4825799D.000E06C3-4825799D.0012A0F1@zte.com.cn> 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_5DF53972F7E9134782DCE51624466FE50AD55FDAD9USNAVSXCHMBSC_" 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" <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: Tue, 07 Feb 2012 15:12:03 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD55FDAD9USNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lizhong, the existing LSR-id will do the job and should be supported since the LSR-i= d need not be an IP address. Most implementations will actually populate th= e field with a /32 address in IPv4 and thus If necessary we could define a = new format to allow the use of /128 IPv6 addresses. 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 with= out IPv6 adjacency, and only use one adjacency for LDP session in dual-stac= k network. LDP capability is per node capability, not per interface capabil= ity. But for LDP to choose the correct downstream session and output interf= ace for each FEC, it should also check if the output interface is LDP enabl= ed 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 32= bit 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 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 impac= ts. > > Thanks, > Pranjal > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e 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 th= e 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_5DF53972F7E9134782DCE51624466FE50AD55FDAD9USNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19170"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D927410315-07022012><FONT size=3D2= =20 face=3DArial>Lizhong,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D927410315-07022012><FONT size=3D2= =20 face=3DArial>the existing LSR-id will do the job and should be supported si= nce the=20 LSR-id need not be an IP address. Most implementations will actua= lly=20 populate the field with a /32 address in IPv4 and thus If necessary we coul= d=20 define a new format to allow the use of /128=20 IPv6 addresses.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D927410315-07022012><FONT size=3D2= =20 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D927410315-07022012><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> Lizhong Jin=20 [mailto:lizhong.jin@zte.com.cn] <BR><B>Sent:</B> Monday, February 06, 2012 = 10:23=20 PM<BR><B>To:</B> Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissao= ui,=20 Mustapha (Mustapha)<BR><B>Cc:</B> mpls@ietf.org<BR><B>Subject:</B> Re: [mpl= s]=20 Comments on draft-ietf-mpls-ldp-ipv6-06<BR></FONT><BR></DIV> <DIV></DIV><BR><FONT size=3D2 face=3Dsans-serif>Hi,</FONT> <BR><FONT size= =3D2=20 face=3Dsans-serif>I wonder if it is feasible to use LDP capability to adver= tise=20 IPv6 FEC without IPv6 adjacency, and only use one adjacency for LDP session= in=20 dual-stack network. LDP capability is per node capability, not per interfac= e=20 capability. But for LDP to choose the correct downstream session and output= =20 interface for each FEC, it should also check if the output interface is LDP= =20 enabled or not. The link adjacency could be used to assist such kind of=20 checking.</FONT> <BR><BR><FONT size=3D2 face=3Dsans-serif>However, IMO, it = is=20 valuable 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 version num= ber=20 to identify IPv6 LSR-ID. Or we use different 32bit LSR-ID for IPv6 with IPv= 4,=20 but I prefer new format of LSR-ID.</FONT> <BR><BR><FONT size=3D2=20 face=3Dsans-serif>Regards</FONT> <BR><FONT size=3D2 face=3Dsans-serif>Lizho= ng</FONT>=20 <BR><BR><FONT size=3D2 face=3Dsans-serif><BR>>=20 ----------------------------------------------------------------------<BR>&= gt;=20 <BR>> Message: 1<BR>> Date: Tue, 7 Feb 2012 05:28:21 +0530<BR>> Fr= om:=20 "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com><BR>&g= t;=20 To: Vishwas Manral <vishwas.ietf@gmail.com><BR>> Cc: "Aissaoui,=20 Mustapha \(Mustapha\)"<BR>>  =20  <mustapha.aissaoui@alcatel-lucent.com>,  =20 "mpls@ietf.org"<BR>>    <mpls@ietf.org><BR>> Subject:= Re:=20 [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06<BR>> Message-ID:<BR>>= =20  =20  <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.<BR>= >=20 alcatel-lucent.com><BR>>    <BR>> Content-Type: text/pla= in;=20 charset=3D"us-ascii"<BR>> <BR>> I would rather for complete separatio= n with=20 multiple lsr-id because <BR>> having separate link adjacencies does not= =20 really solved any problem.<BR>> Since hello adjacencies are associated w= ith a=20 link, still fate <BR>> sharing would continue over the single ldp/tcp se= ssion=20 for IPV4 and IPV6.<BR>> Having IPV4 and IPV6 specific hello adjacencies = over=20 a link would <BR>> only decide whether such a link is to be programmed f= or=20 IPV4 or IPV6<BR>> egress traffic but I see it as overkill and unnecessar= y=20 scalability impacts.<BR>> <BR>> Thanks,<BR>> Pranjal<BR>>=20 </FONT><BR><PRE>-------------------------------------------------------- ZTE Information Security Notice: The information&n= bsp;contained in this mail is solely property=  of the sender's organization. This mail = ;communication is confidential. Recipients named a= bove are obligated to maintain secrecy and&nb= sp;are not permitted to disclose the contents=  of this communication to others. This email and any files transmitted with&nbs= p;it are confidential and intended solely for=  the use of the individual or entity&nbs= p;to whom they are addressed. If you hav= e received this email in error please no= tify the originator of the message. Any = views expressed in this message are those&nbs= p;of the individual sender. This message has been scanned for viruses&nbs= p;and Spam by ZTE Anti-Spam system. </PRE></BODY></HTML> --_000_5DF53972F7E9134782DCE51624466FE50AD55FDAD9USNAVSXCHMBSC_-- From skraza@cisco.com Tue Feb 7 07:51:43 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 416E021F8819 for <mpls@ietfa.amsl.com>; Tue, 7 Feb 2012 07:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.035 X-Spam-Level: X-Spam-Status: No, score=-4.035 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 3per-jVU5YP0 for <mpls@ietfa.amsl.com>; Tue, 7 Feb 2012 07:51:38 -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 69BD321F8817 for <mpls@ietf.org>; Tue, 7 Feb 2012 07:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=19178; q=dns/txt; s=iport; t=1328629898; x=1329839498; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=pyrD/oIsGB7TjhWLUpEYra9TkNYRKbdn73363OCV2nQ=; b=bQlVStm15Fajcx9BQracmugeKcc8EJ6YfcJ6/2ZS0sFy7MpnLPVp8r44 0O7mPxcbxVHDu/vQXUvCa4whXNV0UG6afUoK9ir0bboMF3mCprr+nXWhB JhnRzH0snq8+Rq2gT5fDaTNH7PCu0k95i+0evrpB6gcDxuRNLe01oHnKB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8GAGlHMU+tJXG8/2dsb2JhbAA4BwOCUawhZQKBBYFyAQEBAwEBAQEPASoYEQgLBQ0BCBEDAQEBAScoBh8JCAEBBAENBRsHh1oJmmoBlySIGk6CeBMBCAUDAwkHAQcHAoNRNgUhJQQOgyIEiBMzjGaLDIMwhD8 X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208,217";a="57005459" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 07 Feb 2012 15:51:37 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q17FpbEp015716; Tue, 7 Feb 2012 15:51:37 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 09:51:37 -0600 Received: from 161.44.193.212 ([161.44.193.212]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Feb 2012 15:51:36 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 07 Feb 2012 10:52:06 -0500 From: Kamran Raza <skraza@cisco.com> To: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, Lizhong Jin <lizhong.jin@zte.com.cn>, "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>, "vishwas.ietf@gmail.com" <vishwas.ietf@gmail.com> Message-ID: <CB56B2D6.26052%skraza@cisco.com> Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlU+vrnSqQEu4oc0qYFtfJC+trqQAUqv8AAAJ2R0A= In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD55FDAD3@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3411456726_7055268" X-OriginalArrivalTime: 07 Feb 2012 15:51:37.0222 (UTC) FILETIME=[5FDCEA60:01CCE5B0] Cc: "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: Tue, 07 Feb 2012 15:51:43 -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_3411456726_7055268 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Mustapha, >> in LDP, the ability to advertise a FEC type between peers is independent= of the adjacency established ... I agree that FEC advertisement should be independent of established adjacency type. However, unconditional FEC/state advertisement (without any capability negotiation) is also not nice. Earlier LDP FECs were defined to be advertised without any of the Capabilities mainly due to lack of Capabilities framework in LDP. With the standardization of LDP Capabilities RFC5561, all new LDP features/FECs [mLDP, ICCP, VPLS LSM] are LDP Capabilities bound and do not face the issues discussed here. That=B9s why, I have an active I-D [draft-ietf-mpls-ldp-ip-pw-capability-00.txt] to address the issues with unconditional advt of legacy/earlier FEC (IP prefix FEC and P2P PW FEC). This I-D is also x-ref=B9ed in LDPv6 draft as well. >> Your point 2 below is about FEC resolution and not FEC advertisement That=B9s right. I=B9d read the proposal from Lizhong as using =B3single=B2 adjacenc= y for both v4/v6, and I don=B9t think that coupling v4/v6 [ link] state to a single adjacency is right thing to do [ re: FEC resolution/fwding setup ] >> Re: Multiple session between same LSR AFAIR, the idea of using more than one LDP session (while using platform-wide label space) between two LSRs has been proposed/discussed in IETF WGs [ MPLS/PWE3] before as well (e.g. ICCP), but was rejected. If I=B9ve to chose between Capabilities based solution and Separate LDP session to support IPv4/IPv6 LDP, I will go with LDP Capabilities based solution. My 2 cents. On 12-02-07 10:03 AM, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> wrote: > Kamran, > in LDP, the ability to advertise a FEC type between peers is independent = of > the adjacency established. I am not sure why this was not an issue for ot= her > FEC types (unicast IPv4 FEC, PW FEC, mLDP p2mp FEC) and it is now for uni= cast > IPv6 FEC prefixes. The user controls which prefix type to advertize/accep= t > to/from a peer via import/export policies and LDP node capability > advertisement. > =20 > You point 2 below is about FEC resolution and not FEC advertisement. When= you > resolve a FEC, you need to check which LSR-id owns the next-hop in the ro= uting > table for the IPv6 prefix and this is provided by the list of interface > addresses in the Address List TLV. If you have received a label for the F= EC > from the LSR-id which owns the IPv6 next-hop, you can resolve the FEC to = that > interface even if the Hello adjacency over that interface is IPv4 only. > =20 > We need to keep that separation between FEC advertisement and adjacency t= ype > for backward compatibility with RFC 5036. What we need in my view is to r= elax > RFC 5036 to allow the setup of multiple LDP adjacencies/sessions between = two > LSRs which use two different LSR-id but the same global label-space-id. T= his > can be done with some rules to avoid loops. Users will then be free to > dedicate an LDP session for IPv6 prefixes and another for IPv4 prefixes m= uch > like the BGP model allows for. > =20 > Regards, > Mustapha. >=20 >=20 > From: Kamran Raza [mailto:skraza@cisco.com] > Sent: Monday, February 06, 2012 11:50 PM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aiss= aoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Lizhong, >=20 > Using single adj [ and just checking local interface enabling for given A= F + > capabilities ] will not suffice/work because: >=20 > 1. LDP capabilities are advertised on peer/session level and do not > correspond to adj capabilities. > 2. An LSR must not be forwarding MPLS on an interface unless/until it ha= s got > an MPLS adj on it =AD extending the same to address families, an LSR must n= ot > forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [ Si= ngle > adj will not convey us remote node=B9s interface capability for given AF, a= nd it > will be incorrect to forward 6 MPLS labelled traffic on it unless we know= that > remote intf is v6 MPLS enabled ] >=20 > My 2 cents. > -- Kamran >=20 > On 12-02-06 10:22 PM, "Lizhong Jin" <lizhong.jin@zte.com.cn> wrote: >=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 inte= rface >> capability. But for LDP to choose the correct downstream session and ou= tput >> 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 >>=20 >> [Kamran]: >>=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 m= ay >> need new LDP version number to identify IPv6 LSR-ID. Or we use differen= t >> 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)" <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> >>> > =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 >>=20 >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail= is >> solely property of the sender's organization. This mail communication i= s >> confidential. Recipients named above are obligated to maintain secrecy a= nd >> are not permitted to disclose the contents of this communication to ot= hers. >> This email and any files transmitted with it are confidential and inten= ded >> solely for the use of the individual or entity to whom they are address= ed. >> If you have received this email in error please notify the originator o= f the >> message. Any views expressed in this message are those of the individua= l >> sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam sys= tem. >>=20 >> =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_3411456726_7055268 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 Hi Mustapha,

>> in L= DP, the ability to advertise a FEC type between peers is independent of the = adjacency established ...

I agree that FEC advertisement should be independent of established adjacen= cy type. However, unconditional FEC/state advertisement (without any capabil= ity negotiation) is also not nice. Earlier LDP FECs were defined to be adver= tised without any of the Capabilities mainly due to lack of Capabilities fra= mework in LDP. With the standardization of LDP Capabilities RFC5561, all new= LDP features/FECs [mLDP, ICCP, VPLS LSM] are LDP Capabilities bound and do = not face the issues discussed here. That’s why, I have an active I-D [= draft-ietf-mpls-ldp-ip-pw-capabilit= y-00.txt] to address the issues with uncond= itional advt of legacy/earlier FEC (IP prefix FEC and P2P PW FEC). This I-D = is also x-ref’ed in LDPv6 draft as well.

>> Your= point 2 below is about FEC resolution and not FEC advertisement
That’s right. = I’d read the proposal from Lizhong as using “single” adjac= ency for both v4/v6, and I don’t think that coupling v4/v6 [ link] sta= te to a single adjacency is right thing to do [ re: FEC resolution/fwding se= tup ]

>> Re: Multiple session between same LSR
AFAIR, the idea of using more than one LDP session (while using platform-wi= de label space) between two LSRs has been proposed/discussed in IETF WGs [ M= PLS/PWE3] before as well (e.g. ICCP), but was rejected.

If I’ve to chose between Capabilities based solution and Separate LDP= session to support IPv4/IPv6 LDP, I will go with LDP Capabilities based sol= ution.

My 2 cents.

On 12-02-07 10:03 AM, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= > wrote:

K= amran,
in LDP, the ability to advertise a FEC type between peers is independent of= the adjacency established. I am not sure why this was not an issue for othe= r FEC types (unicast IPv4 FEC, PW FEC, mLDP p2mp FEC) and it is now for unic= ast IPv6 FEC prefixes. The user controls which prefix type to advertize/acce= pt to/from a peer via import/export policies and LDP node capability adverti= sement.
You point 2 below is about FEC resolution and not= FEC advertisement. When you resolve a FEC, you need to check which LSR-id o= wns the next-hop in the routing table for the IPv6 prefix and this is provid= ed by the list of interface addresses in the Address List TLV. If you have r= eceived a label for the FEC from the LSR-id which owns the IPv6 next-hop, yo= u can resolve the FEC to that interface even if the Hello adjacency over tha= t interface is IPv4 only.

We need to keep that separation between FEC adver= tisement and adjacency type for backward compatibility with RFC 5036. What w= e need in my view is to relax RFC 5036 to allow the setup of multiple LDP ad= jacencies/sessions between two LSRs which use two different LSR-id but the s= ame global label-space-id. This can be done with some rules to avoid loops. = Users will then be free to dedicate an LDP session for IPv6 prefixes and ano= ther for IPv4 prefixes much like the BGP model allows for.
Regards,
Mustapha.

From: Kamran Raza [mailto:skraza@cisco.com]
Sent: Monday, February 06, 2012 11:50 PM
To: Lizhong Jin; 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 Lizhong,

Using single adj [ and just checking local interface enabling for given AF = + capabilities ] will not suffice/work because:

 1. LDP capabilities are advertised on peer/session level and do not c= orrespond to adj capabilities.
 2. An LSR must not be forwarding MPLS on an interface unless/until it= has got an MPLS adj on it – extending the same to address families, a= n LSR must not forward MPLS v6 on an interface unless it has got MPLS v6 adj= on it. [ Single adj will not convey us remote node’s interface capabi= lity for given AF, and it will be incorrect to forward 6 MPLS labelled traff= ic on it unless we know that remote intf is v6 MPLS enabled ]

 My 2 cents.
-- Kamran

On 12-02-06 10:22 PM, "Lizhong Jin" <lizhong.jin@zte.com.cn> wrote:


Hi,
I wonder if it is feasible to use LDP  capability to advertise IPv6 FE= C without IPv6 adjacency, and only use one  adjacency for LDP session i= n dual-stack network. LDP capability is per node  capability, not per i= nterface capability. But for LDP to choose the correct  downstream sess= ion and output interface for each FEC, it should also check if  the out= put interface is LDP enabled or not. The link adjacency could be used  = to assist such kind of checking.

[Kamran]:

However, IMO, it is  valuable to allow two independent LDP sessions fo= r IPv4 and IPv6 as an option.  Regarding the format definition in RFC50= 36, 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\)"
>    <m= ustapha.aissaoui@alcatel-lucent.com>,   "mpls@ietf.org"
>     <mpls@ietf.org&= gt;
>  Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>  Message-ID:
>    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHM= BSA3.in.
>  alcatel-lucent.com>
>    
> Content-Type:  text/plain; charset=3D"us-ascii"
>
> 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 <= BR> > 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.
>  
> Thanks,
> Pranjal
>  

--------------------------------------------------------
ZTE  Information Security Notice: The information contained in this ma= il is solely  property of the sender's organization. This mail communic= ation is  confidential. Recipients named above are obligated to maintai= n secrecy and are  not permitted to disclose the contents of this commu= nication to  others.
This email and any files transmitted with it are confidential and  int= ended 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 s= ystem.

 
__________= _____________________________________
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_3411456726_7055268-- From mustapha.aissaoui@alcatel-lucent.com Tue Feb 7 10:30: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 B95D321F88BF for ; Tue, 7 Feb 2012 10:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.948 X-Spam-Level: X-Spam-Status: No, score=-6.948 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 nEoMmVpphHNL for ; Tue, 7 Feb 2012 10:30:51 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0A92921F88CA for ; Tue, 7 Feb 2012 10:30:50 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q17IUhFQ025106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2012 12:30:43 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q17IUh3m030999 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Feb 2012 12:30:43 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 7 Feb 2012 12:30:43 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: Kamran Raza , Lizhong Jin , "Dutta, Pranjal K (Pranjal)" , "vishwas.ietf@gmail.com" Date: Tue, 7 Feb 2012 12:30:42 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlU+vrnSqQEu4oc0qYFtfJC+trqQAUqv8AAAJ2R0AAAFXs8A== Message-ID: <5DF53972F7E9134782DCE51624466FE50AD56AC58E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD55FDAD3@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_5DF53972F7E9134782DCE51624466FE50AD56AC58EUSNAVSXCHMBSC_" 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.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: Tue, 07 Feb 2012 18:30:52 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD56AC58EUSNAVSXCHMBSC_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kamran, I agree that LDP capability is good to have and I support that work. It how= ever does not solve the issue at hand. I did not follow the discussions but what were the main objections to multi= ple adjacencies for the same label space? If not that then we are only left= with the virtualization of LDP to create multiple global label spaces. Mustapha. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kam= ran Raza Sent: Tuesday, February 07, 2012 10:52 AM To: Aissaoui, Mustapha (Mustapha); 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 Hi Mustapha, >> in LDP, the ability to advertise a FEC type between peers is independent= of the adjacency established ... I agree that FEC advertisement should be independent of established adjacen= cy type. However, unconditional FEC/state advertisement (without any capabi= lity negotiation) is also not nice. Earlier LDP FECs were defined to be adv= ertised without any of the Capabilities mainly due to lack of Capabilities = framework in LDP. With the standardization of LDP Capabilities RFC5561, all= new LDP features/FECs [mLDP, ICCP, VPLS LSM] are LDP Capabilities bound an= d do not face the issues discussed here. That=92s why, I have an active I-D= [draft-ietf-mpls-ldp-ip-pw-capability-00.txt] to address the issues with u= nconditional advt of legacy/earlier FEC (IP prefix FEC and P2P PW FEC). Thi= s I-D is also x-ref=92ed in LDPv6 draft as well. >> Your point 2 below is about FEC resolution and not FEC advertisement That=92s right. I=92d read the proposal from Lizhong as using =93single=94 = adjacency for both v4/v6, and I don=92t think that coupling v4/v6 [ link] s= tate to a single adjacency is right thing to do [ re: FEC resolution/fwding= setup ] >> Re: Multiple session between same LSR AFAIR, the idea of using more than one LDP session (while using platform-wi= de label space) between two LSRs has been proposed/discussed in IETF WGs [ = MPLS/PWE3] before as well (e.g. ICCP), but was rejected. If I=92ve to chose between Capabilities based solution and Separate LDP ses= sion to support IPv4/IPv6 LDP, I will go with LDP Capabilities based soluti= on. My 2 cents. On 12-02-07 10:03 AM, "Aissaoui, Mustapha (Mustapha)" wrote: Kamran, in LDP, the ability to advertise a FEC type between peers is independent of= the adjacency established. I am not sure why this was not an issue for oth= er FEC types (unicast IPv4 FEC, PW FEC, mLDP p2mp FEC) and it is now for un= icast IPv6 FEC prefixes. The user controls which prefix type to advertize/a= ccept to/from a peer via import/export policies and LDP node capability adv= ertisement. You point 2 below is about FEC resolution and not FEC advertisement. When y= ou resolve a FEC, you need to check which LSR-id owns the next-hop in the r= outing table for the IPv6 prefix and this is provided by the list of interf= ace addresses in the Address List TLV. If you have received a label for the= FEC from the LSR-id which owns the IPv6 next-hop, you can resolve the FEC = to that interface even if the Hello adjacency over that interface is IPv4 o= nly. We need to keep that separation between FEC advertisement and adjacency typ= e for backward compatibility with RFC 5036. What we need in my view is to r= elax RFC 5036 to allow the setup of multiple LDP adjacencies/sessions betwe= en two LSRs which use two different LSR-id but the same global label-space-= id. This can be done with some rules to avoid loops. Users will then be fre= e to dedicate an LDP session for IPv6 prefixes and another for IPv4 prefixe= s much like the BGP model allows for. Regards, Mustapha. ________________________________ From: Kamran Raza [mailto:skraza@cisco.com] Sent: Monday, February 06, 2012 11:50 PM To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissao= ui, Mustapha (Mustapha) Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong, Using single adj [ and just checking local interface enabling for given AF = + capabilities ] will not suffice/work because: 1. LDP capabilities are advertised on peer/session level and do not corres= pond to adj capabilities. 2. An LSR must not be forwarding MPLS on an interface unless/until it has = got an MPLS adj on it =96 extending the same to address families, an LSR mu= st not forward MPLS v6 on an interface unless it has got MPLS v6 adj on it.= [ Single adj will not convey us remote node=92s interface capability for g= iven AF, and it will be incorrect to forward 6 MPLS labelled traffic on it = unless we know that remote intf is v6 MPLS enabled ] My 2 cents. -- Kamran On 12-02-06 10:22 PM, "Lizhong Jin" wrote: Hi, I wonder if it is feasible to use LDP capability to advertise IPv6 FEC wit= hout IPv6 adjacency, and only use one adjacency for LDP session in dual-st= ack network. LDP capability is per node capability, not per interface capa= bility. But for LDP to choose the correct downstream session and output in= terface 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 ch= ecking. [Kamran]: However, IMO, it is valuable to allow two independent LDP sessions for IPv= 4 and IPv6 as an option. Regarding the format definition in RFC5036, we ma= y 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 impa= cts. > > 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 othe= rs. 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 individ= ual 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 --_000_5DF53972F7E9134782DCE51624466FE50AD56AC58EUSNAVSXCHMBSC_ 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=3D749420116-07022012><FONT size=3D2= =20 face=3DArial>Hi Kamran,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D749420116-07022012><FONT size=3D2= face=3DArial>I=20 agree that LDP capability is good to have and I support that work. It= =20 however does not solve the issue at hand. </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D749420116-07022012><FONT size=3D2= =20 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D749420116-07022012><FONT size=3D2= face=3DArial>I=20 did not follow the discussions but what were the main objections=20 to multiple adjacencies for the same label space? If not that then we = are=20 only left with the virtualization of LDP to create multiple global label=20 spaces.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D749420116-07022012><FONT size=3D2= =20 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D749420116-07022012><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> mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] <B>On Behalf Of </B>Kamran Raza<BR><B>Sent:<= /B>=20 Tuesday, February 07, 2012 10:52 AM<BR><B>To:</B> Aissaoui, Mustapha (Musta= pha);=20 Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com<BR><B>Cc:</= B>=20 mpls@ietf.org<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">Hi Mustapha,<BR><BR>>> </SPAN></FONT><SPAN= =20 style=3D"FONT-SIZE: 11pt"><FONT face=3DArial>in LDP, the ability to adverti= se a FEC=20 type between peers is independent of the adjacency established=20 ...<BR></FONT><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><BR>I agree= that=20 FEC advertisement should be independent of established adjacency type. Howe= ver,=20 unconditional FEC/state advertisement (without any capability negotiation) = is=20 also not nice. Earlier LDP FECs were defined to be advertised without any o= f the=20 Capabilities mainly due to lack of Capabilities framework in LDP. With the= =20 standardization of LDP Capabilities RFC5561, all new LDP features/FECs [mLD= P,=20 ICCP, VPLS LSM] are LDP Capabilities bound and do not face the issues discu= ssed=20 here. That=92s why, I have an active I-D [</FONT></SPAN><FONT color=3D#1d36= ef><FONT=20 size=3D2><FONT face=3D"Courier, Courier New"><SPAN=20 style=3D"FONT-SIZE: 10pt"><U>draft-ietf-mpls-ldp-ip-pw-capability-00.txt]=20 </U></SPAN></FONT></FONT></FONT><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN style=3D"FONT-SIZE: 11pt"= >to=20 address the issues with unconditional advt of legacy/earlier FEC (IP prefix= FEC=20 and P2P PW FEC). This I-D is also x-ref=92ed in LDPv6 draft as well.=20 <BR><BR>>> </SPAN></FONT><SPAN style=3D"FONT-SIZE: 11pt"><FONT=20 face=3DArial>Your point 2 below is about FEC resolution and not FEC=20 advertisement<BR></FONT><FONT face=3D"Calibri, Verdana, Helvetica, Arial">T= hat=92s=20 right. I=92d read the proposal from Lizhong as using =93single=94 adjacency= for both=20 v4/v6, and I don=92t think that coupling v4/v6 [ link] state to a single ad= jacency=20 is right thing to do [ re: FEC resolution/fwding setup ]<BR><BR>>> Re= :=20 Multiple session between same LSR<BR>AFAIR, the idea of using more than one= LDP=20 session (while using platform-wide label space) between two LSRs has been=20 proposed/discussed in IETF WGs [ MPLS/PWE3] before as well (e.g. ICCP), but= was=20 rejected.<BR><BR>If I=92ve to chose between Capabilities based solution and= =20 Separate LDP session to support IPv4/IPv6 LDP, I will go with LDP Capabilit= ies=20 based solution.<BR><BR>My 2 cents.<BR><BR>On 12-02-07 10:03 AM, "Aissaoui,= =20 Mustapha (Mustapha)" <<A=20 href=3D"mustapha.aissaoui@alcatel-lucent.com">mustapha.aissaoui@alcatel-luc= ent.com</A>>=20 wrote:<BR><BR></FONT></SPAN> <BLOCKQUOTE><SPAN style=3D"FONT-SIZE: 11pt"><FONT face=3DArial>Kamran,<BR>i= n LDP,=20 the ability to advertise a FEC type between peers is independent of the=20 adjacency established. I am not sure why this was not an issue for other = FEC=20 types (unicast IPv4 FEC, PW FEC, mLDP p2mp FEC) and it is now for unicast= IPv6=20 FEC prefixes. The user controls which prefix type to advertize/accept to/= from=20 a peer via import/export policies and LDP node capability=20 advertisement.<BR></FONT><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><BR></FONT><FONT face=3DArial= >You=20 point 2 below is about FEC resolution and not FEC advertisement. When you= =20 resolve a FEC, you need to check which LSR-id owns the next-hop in the ro= uting=20 table for the IPv6 prefix and this is provided by the list of interface=20 addresses in the Address List TLV. If you have received a label for the F= EC=20 from the LSR-id which owns the IPv6 next-hop, you can resolve the FEC to = that=20 interface even if the Hello adjacency over that interface is IPv4 only.=20 <BR></FONT><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><BR></FONT><= FONT=20 face=3DArial>We need to keep that separation between FEC advertisement an= d=20 adjacency type for backward compatibility with RFC 5036. What we need in = my=20 view is to relax RFC 5036 to allow the setup of multiple LDP=20 adjacencies/sessions between two LSRs which use two different LSR-id but = the=20 same global label-space-id. This can be done with some rules to avoid loo= ps.=20 Users will then be free to dedicate an LDP session for IPv6 prefixes and= =20 another for IPv4 prefixes much like the BGP model allows for.<BR></FONT><= FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><BR></FONT><FONT=20 face=3DArial>Regards,<BR>Mustapha.<BR></FONT><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><BR> <HR align=3Dcenter SIZE=3D3 width=3D"100%"> </FONT><FONT face=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> Kamr= an Raza=20 [<A href=3D"mailto:skraza@cisco.com">mailto:skraza@cisco.com</A>]=20 <BR><B>Sent:</B> Monday, February 06, 2012 11:50 PM<BR><B>To:</B> Lizhong= Jin;=20 Dutta, Pranjal K (Pranjal); <A=20 href=3D"vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</A>; Aissaoui, Mus= tapha=20 (Mustapha)<BR><B>Cc:</B> <A=20 href=3D"mpls@ietf.org">mpls@ietf.org</A><BR><B>Subject:</B> Re: [mpls] Co= mments=20 on draft-ietf-mpls-ldp-ipv6-06<BR></FONT><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><BR>Hi Lizhong,<BR><BR>Using = single=20 adj [ and just checking local interface enabling for given AF + capabilit= ies ]=20 will not suffice/work because:<BR><BR> 1. LDP capabilities are adver= tised=20 on peer/session level and do not correspond to adj capabilities.<BR> = ;2.=20 An LSR must not be forwarding MPLS on an interface unless/until it has go= t an=20 MPLS adj on it =96 extending the same to address families, an LSR must no= t=20 forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [ Si= ngle=20 adj will not convey us remote node=92s interface capability for given AF,= and it=20 will be incorrect to forward 6 MPLS labelled traffic on it unless we know= that=20 remote intf is v6 MPLS enabled ]<BR><BR> My 2 cents.<BR>--=20 Kamran<BR><BR>On 12-02-06 10:22 PM, "Lizhong Jin" <<A=20 href=3D"lizhong.jin@zte.com.cn">lizhong.jin@zte.com.cn</A>>=20 wrote:<BR><BR></FONT></SPAN> <BLOCKQUOTE><SPAN style=3D"FONT-SIZE: 11pt"><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><BR>Hi, <BR>I wonder if it = is=20 feasible to use LDP  capability to advertise IPv6 FEC without IPv6= =20 adjacency, and only use one  adjacency for LDP session in dual-sta= ck=20 network. LDP capability is per node  capability, not per interface= =20 capability. But for LDP to choose the correct  downstream session = and=20 output interface for each FEC, it should also check if  the output= =20 interface is LDP enabled or not. The link adjacency could be used  = ;to=20 assist such kind of checking. <BR><BR>[Kamran]:<BR><BR>However, IMO, it= is=20  valuable to allow two independent LDP sessions for IPv4 and IPv6 = as an=20 option.  Regarding the format definition in RFC5036, we may need n= ew=20 LDP version number  to identify IPv6 LSR-ID. Or we use different 3= 2bit=20 LSR-ID for IPv6 with IPv4,  but I prefer new format of LSR-ID.=20 <BR><BR>Regards <BR>Lizhong  <BR><BR><BR>>=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>> = Cc:=20  "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=20 href=3D"mpls@ietf.org">mpls@ietf.org</A>><BR>>  Subject: Re:= [mpls]=20 Comments on draft-ietf-mpls-ldp-ipv6-06<BR>>  Message-ID:<BR>&g= t;=20    <<A=20 href=3D"C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in">C= 584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in</A>.<BR>>=20  alcatel-lucent.com><BR>>    <BR>>=20 Content-Type:  text/plain; charset=3D"us-ascii"<BR>> <BR>> I= would=20 rather for complete  separation with multiple lsr-id because <BR>&= gt;=20 having separate link  adjacencies does not really solved any=20 problem.<BR>> Since hello  adjacencies are associated with a li= nk,=20 still fate <BR>> sharing would  continue over the single ldp/tc= p=20 session for IPV4 and IPV6.<BR>> Having  IPV4 and IPV6 specific = hello=20 adjacencies over a link would <BR>> only  decide whether such a= link=20 is to be programmed for IPV4 or IPV6<BR>> egress  traffic but I= see=20 it as overkill and unnecessary scalability impacts.<BR>>  <BR>&= gt;=20 Thanks,<BR>> Pranjal<BR>>=20  <BR><BR>--------------------------------------------------------<= BR>ZTE=20  Information Security Notice: The information contained in this ma= il is=20 solely  property of the sender's organization. This mail communica= tion=20 is  confidential. Recipients named above are obligated to maintain= =20 secrecy and are  not permitted to disclose the contents of this=20 communication to  others.<BR>This email and any files transmitted = with=20 it are confidential and  intended solely for the use of the indivi= dual=20 or entity to whom they are  addressed. If you have received this e= mail=20 in error please notify the  originator of the message. Any views=20 expressed in this message are those of  the individual sender.<BR>= This=20 message has been scanned for viruses and Spam  by ZTE Anti-Spam=20 system.<BR><BR> <BR> <HR align=3Dcenter SIZE=3D3 width=3D"95%"> </FONT></SPAN><FONT size=3D2><FONT face=3D"Consolas, Courier New, Couri= er"><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.or= g/mailman/listinfo/mpls</A><BR></SPAN></FONT></FONT></BLOCKQUOTE></BLOCKQUO= TE><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_5DF53972F7E9134782DCE51624466FE50AD56AC58EUSNAVSXCHMBSC_-- From pranjal.dutta@alcatel-lucent.com Tue Feb 7 10:40:47 2012 Return-Path: <pranjal.dutta@alcatel-lucent.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 72DA511E808A for <mpls@ietfa.amsl.com>; Tue, 7 Feb 2012 10:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.931 X-Spam-Level: X-Spam-Status: No, score=-9.931 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SbLM2xNeoB66 for <mpls@ietfa.amsl.com>; Tue, 7 Feb 2012 10:40:44 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0396B11E8088 for <mpls@ietf.org>; Tue, 7 Feb 2012 10:40:43 -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 q17IeZqN012335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2012 12:40:38 -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 q17IeYkd001931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Feb 2012 00:10:35 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 8 Feb 2012 00:10:34 +0530 From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> To: Kamran Raza <skraza@cisco.com>, Lizhong Jin <lizhong.jin@zte.com.cn>, "vishwas.ietf@gmail.com" <vishwas.ietf@gmail.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> Date: Wed, 8 Feb 2012 00:10:31 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlU+vrnSqQEu4oc0qYFtfJC+trqQAcuSTg Message-ID: <C584046466ED224CA92C1BC3313B963E09EFF4BC41@INBANSXCHMBSA3.in.alcatel-lucent.com> References: <OFA7A7CD93.8FCD9D27-ON4825799D.000E06C3-4825799D.0012A0F1@zte.com.cn> <CB56179D.26021%skraza@cisco.com> In-Reply-To: <CB56179D.26021%skraza@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_C584046466ED224CA92C1BC3313B963E09EFF4BC41INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "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: Tue, 07 Feb 2012 18:40:47 -0000 --_000_C584046466ED224CA92C1BC3313B963E09EFF4BC41INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Using separate adjacency to decide capabilities on an interface would= kick start several wars as the issue not just limited to IPV4 vs IPV6. The= same is applicable to multicast capabilities as well when an operator may = have multiple ECMP links between two nodes but certain links/cards do not h= ave multicast capabilities. This is just one example and we have more such = capabiities. So as of now such link specific restrictions should be imposed= by local behaviors rather than coupling with adjacency types. Otherwise LD= P capabilities should be extended to be used in per interface ldp hello mes= sages where a single adjacency would be tagged multiple capabilities. I wou= ld believe that is more rightful approach than maintaining separate hellos = adjacencies for each capability that would grow exponentially at some point= . Thanks, Pranjal ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kam= ran Raza Sent: Monday, February 06, 2012 8:50 PM To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissao= ui, Mustapha (Mustapha) Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong, Using single adj [ and just checking local interface enabling for given AF = + capabilities ] will not suffice/work because: 1. LDP capabilities are advertised on peer/session level and do not corres= pond to adj capabilities. 2. An LSR must not be forwarding MPLS on an interface unless/until it has = got an MPLS adj on it - extending the same to address families, an LSR must= not forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [= Single adj will not convey us remote node's interface capability for given= AF, and it will be incorrect to forward 6 MPLS labelled traffic on it unle= ss we know that remote intf is v6 MPLS enabled ] My 2 cents. -- Kamran On 12-02-06 10:22 PM, "Lizhong Jin" <lizhong.jin@zte.com.cn> wrote: Hi, I wonder if it is feasible to use LDP capability to advertise IPv6 FEC with= out IPv6 adjacency, and only use one adjacency for LDP session in dual-stac= k network. LDP capability is per node capability, not per interface capabil= ity. But for LDP to choose the correct downstream session and output interf= ace for each FEC, it should also check if the output interface is LDP enabl= ed or not. The link adjacency could be used to assist such kind of checking= . [Kamran]: 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 32= bit 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 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 impac= ts. > > Thanks, > Pranjal > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e 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 th= e 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 --_000_C584046466ED224CA92C1BC3313B963E09EFF4BC41INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi,

      Using s= eparate adjacency to decide capabilities on an interface would kick start several wars as the issue not just limited to IPV4 vs IPV6. The same is applicable to multicast capabilit= ies as well when an operator may have multiple ECMP links between two nodes but certain links/cards do not have multicast capabilities. This is just one example and we have more such capabiities. So as of now such link specific = restrictions should be imposed by local behaviors rather than coupling with adjacency ty= pes. Otherwise LDP capabilities should be extended to be used in per interface l= dp hello messages where a single adjacency would be tagged multiple capabiliti= es. I would believe that is more rightful approach than maintaining separate he= llos adjacencies for each capability that would grow exponentially at some point= .

 

Thanks,

Pranjal

     

 

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behal= f Of Kamran Raza
Sent: Monday, February 06, 2= 012 8:50 PM
To: Lizhong Jin; 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 Lizhong,

Using single adj [ and just checking local interface enabling for given AF = + capabilities ] will not suffice/work because:

 1. LDP capabilities are advertised on peer/session level and do not correspond to adj capabilities.
 2. An LSR must not be forwarding MPLS on an interface unless/until it= has got an MPLS adj on it – extending the same to address families, an LS= R must not forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [ Sing= le adj will not convey us remote node’s interface capability for given A= F, and it will be incorrect to forward 6 MPLS labelled traffic on it unless we know t= hat remote intf is v6 MPLS enabled ]

 My 2 cents.
-- Kamran

On 12-02-06 10:22 PM, "Lizhong Jin" <lizhong.jin@zte.com.cn> wrote:


Hi,
I wonder if it is feasible to use LDP capability to advertise IPv6 FEC with= out IPv6 adjacency, and only use one adjacency for LDP session in dual-stack network. LDP capability is per node capability, not per interface capabilit= y. But for LDP to choose the correct downstream session and output interface f= or each FEC, it should also check if the output interface is LDP enabled or no= t. The link adjacency could be used to assist such kind of checking.

[Kamran]:

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-I= D 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>
> To: Vishwas Manral <vishwas.ietf@gmail.com>
> Cc: "Aissaoui, Mustapha \(Mustapha\)"
>    <mustapha.aissaoui@alcatel-lucent.com>,  "mpls@ietf.org"
>    <mpls@ietf.org><= br> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> Message-ID:
>    <C5840= 46466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.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 IP= V6.
> 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

--_000_C584046466ED224CA92C1BC3313B963E09EFF4BC41INBANSXCHMBSA_-- From mach.chen@huawei.com Tue Feb 7 17:17: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 D5F2921F84EC; Tue, 7 Feb 2012 17:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 A45RJfV8wDRu; Tue, 7 Feb 2012 17:17:39 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2639B21F84F6; Tue, 7 Feb 2012 17:17:36 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ100D8KVKQPD@szxga03-in.huawei.com>; Wed, 08 Feb 2012 09:17:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ1000N0VJ950@szxga03-in.huawei.com>; Wed, 08 Feb 2012 09:17:14 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX67176; Wed, 08 Feb 2012 09:17:14 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 08 Feb 2012 09:16:34 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.206]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Wed, 08 Feb 2012 09:17:45 +0800 Date: Wed, 08 Feb 2012 01:17:03 +0000 From: Mach Chen In-reply-to: <4F31285C.6040107@labn.net> X-Originating-IP: [10.108.4.51] To: Lou Berger , Francesco Fondelli Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: [CCAMP] Discussion on how to carry the Global_ID Thread-index: AQHM3mtqrImy7nMdPk6BWVdOo7CN0ZYqcwYAgABMRgCABdMwAIAAD9MAgAAHloCAAE2MAIABRMig X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> <4F31285C.6040107@labn.net> Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] [CCAMP] Discussion on how to carry the Global_ID 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, 08 Feb 2012 01:17:41 -0000 SGkgTG91LA0KDQpJIGFtIGFsd2F5cyBhc3N1bWUgdGhhdCB0aGUgWjktdHVubmVsLW51bSBlcXVh bHMgdG8gQTEtdHVubmVsLW51bSAoZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCkuIFRo ZSBtb3RpdmF0aW9uIChmcm9tIHRoZSB0ZXh0IG9mIFJGQzYzNzAgYW5kIHRoZSBwYXN0IGRpc2N1 c3Npb24gb24gTVBMUy1UUCBpZGVudGlmaWVyKSBvZiB0d28gdHVubmVsLW51bXMgaXMgZm9yIHNp bXBsaWZ5aW5nIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBzaWduYWxpbmcsIGZvciBjby1yb3V0 ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHR3byB0dW5uZWwtbnVtcyBhcmUgdW5uZWNlc3NhcnkuIElm IEkgYW0gd3JvbmcsIHBsZWFzZSBjb3JyZWN0IG1lLihjYyBNUExTIFdHKQ0KDQpJTUhPLCB0aGUg c2ltcGxlc3Qgd2F5IGlzIHRvIGV4cGxpY2l0bHkgY2xhcmlmeSB0aGF0IGZvciBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbCBMU1AsIEExLXR1bm5lbC1udW09WjktdHVubmVsLW51bSwgbWF5YmUgYSBj bGFyaWZpY2F0aW9uIGVycmF0YSBpcyBuZWVkZWQgZm9yIFJGQzYzNzAuDQoNCkJlc3QgcmVnYXJk cywNCk1hY2gNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjY2FtcC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+IExvdSBCZXJnZXINCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDcsIDIwMTIgOToz NCBQTQ0KPiBUbzogRnJhbmNlc2NvIEZvbmRlbGxpDQo+IENjOiBjY2FtcEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW0NDQU1QXSBEaXNjdXNzaW9uIG9uIGhvdyB0byBjYXJyeSB0aGUgR2xvYmFs X0lEDQo+IA0KPiBGcmFuY2VzY28sDQo+IAlGcm9tIG15IHBlcnNwZWN0aXZlLCB0aGUgKG1pbmlt dW0pIHJlcXVpcmVtZW50cyBhcmUgYmVpbmcgZHJpdmVuIGJ5DQo+IHJmYzYzNzAuIFRha2UgYSBs b29rIGF0IHNlY3Rpb25zIDUuMiBhbmQgNS4zLCBhbmQgc2VlIGlmIHlvdSBzdGlsbCB0aGluaw0K PiBtb3JlIG1lY2hhbmlzbXMgYXJlIGJlaW5nIGRlZmluZWQgdGhhbiBpcyBuZWNlc3NhcnkuDQo+ IA0KPiBMb3UNCj4gDQo+IE9uIDIvNy8yMDEyIDM6NTYgQU0sIEZyYW5jZXNjbyBGb25kZWxsaSB3 cm90ZToNCj4gPg0KPiA+IEFtIEkgdGhlIG9ubHkgb25lIGhlcmUgdGhhdCBmZWVscyAidW5jb21m b3J0YWJsZSIgd2l0aCB0aGlzIGFwcHJvYWNoIGFuZA0KPiA+IHRoaXMgYWRkaXRpb25hbCBaOS1U dW5uZWxfTnVtIGluZGV4IGluIEdNUExTIGZseWluZyBmcm9tIGVncmVzcyB0bw0KPiA+IGluZ3Jl c3MgKGZvciBubyByZWFzb24/IT8pPyBJdCBtaWdodCBiZSBuYWl2ZSBvciBldmVuIHN0dXBpZCBi dXQgSSdkDQo+ID4gbGlrZSB0byB1bmRlcnN0YW5kIHdoeSB3ZSBoYXZlIHRvIGFkZCBhbm90aGVy IGluZGV4Li4uIHBsZWFzZSBzaGVkIHNvbWUNCj4gPiBsaWdodCBvbiBtZS4NCj4gPg0KPiA+IFtJ J20gdGFsa2luZyBhYm91dCBjby1yb3V0ZWQgYmlkaSwgSSBkb24ndCBjYXJlIGFib3V0IGFzc29j aWF0ZWRdDQo+ID4NCj4gPiB0aGFuayB5b3UNCj4gPiBjaWFvDQo+ID4gRkYNCj4gPg0KPiA+IDIw MTIvMi83IDx6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20u Y24+Pg0KPiA+DQo+ID4NCj4gPiAgICAgVmVybw0KPiA+DQo+ID4gICAgIFdoeSBpcyB0dW5uZWwg bnVtYmVyIG5vdCBrbm93biBieSBub2RlIEE/IFRoZSB0dW5uZWwgbnVtYmVyIHNob3VsZA0KPiA+ ICAgICBoYXMgYmVlbiBjYXJyaWVkIGluIFNlc3Npb24gYW5kIFNlbmRlciBUZW1wbGF0ZS9GaWx0 ZXIgU3BlYyBvYmplY3QNCj4gPiAgICAgYW5kIGV4Y2hhbmdlZCBieSBub2RlIEEgYW5kIG5vZGUg WiBkdXJpbmcgdGhlIExTUCBzZXQtdXAuIENvcnJlY3QgbWUNCj4gPiAgICAgaWYgSSBhbSB3cm9u Zy4NCj4gPg0KPiA+ICAgICBBY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uIG9mIFJGQzYzNzAs IHNlY3Rpb24gNS4xDQo+ID4gICAgICAgIEF0IGVhY2ggZW5kIHBvaW50LCBhIHR1bm5lbCBpcyB1 bmlxdWVseSBpZGVudGlmaWVkIGJ5IHRoZSBlbmQgcG9pbnQncw0KPiA+ICAgICAgIE5vZGVfSUQg YW5kIGEgbG9jYWxseSBhc3NpZ25lZCB0dW5uZWwgbnVtYmVyLiAgU3BlY2lmaWNhbGx5LCBhDQo+ ID4gICAgICAgIlR1bm5lbCBOdW1iZXIiIChUdW5uZWxfTnVtKSBpcyBhIDE2LWJpdCB1bnNpZ25l ZCBpbnRlZ2VyIHVuaXF1ZQ0KPiA+ICAgICAgIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUgTm9k ZV9JRC4gIFRoZSBtb3RpdmF0aW9uIGZvciBlYWNoIGVuZA0KPiBwb2ludA0KPiA+ICAgICAgIGhh dmluZyBpdHMgb3duIHR1bm5lbCBudW1iZXIgaXMgdG8gYWxsb3cgYSBjb21wYWN0IGZvcm0gZm9y IHRoZQ0KPiA+ICAgICAgIE1FUF9JRC4NCj4gPg0KPiA+ICAgICBXaGljaCBtZWFucyB0aGF0IGZv ciBjby1yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCwgdGhlcmUgYXJlIHR3bw0KPiA+ICAgICB0dW5u ZWwgbnVtYmVycywgb25lIGlzIGxvY2FsbHkgYXNzaWduZWQgYXQgbm9kZSBBIGFuZCB0aGUgb3Ro ZXIgaXMNCj4gPiAgICAgbG9jYWxseSBhc3NpZ25lZCBhdCBub2RlIFouDQo+ID4gICAgIElmIHRo ZSBzaWduYWxpbmcgbWVzc2FnZSBpcyBpbml0aWFsaXplZCBhdCBub2RlIEEsIHRoZSB0dW5uZWwg bnVtYmVyDQo+ID4gICAgIGNhcnJpZWQgaW4gU2Vzc2lvbi9TZW5kZXIgVGVtcGxhdGUgb2JqZWN0 cyBpcyBsb2NhbGx5IGFzc2lnbmVkIGF0DQo+ID4gICAgIG5vZGUgQS4gT2YgY291cnNlLCBhIG5l dw0KPiA+ICAgICBDLXR5cGUsbGlrZSB0eXBlPTgsIGNhbiBiZSBkZWZpbmVkIGluIHRoZSBjbGFz cyBvZiBTRVNTSU9OIHRvIGNhcnJ5DQo+ID4gICAgIGJhY2sgdGhlIHR1bm5lbCBudW1iZXIgYXNz aWduZWQgYXQgbm9kZSBaOyBidXQgYWNjb3JkaW5nIHRvIHRoZQ0KPiA+ICAgICBkaXNjdXNzaW9u IHdpdGggR2VvcmdlLCBJIGRvIG5vdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB3aGljaCBpcw0K PiA+ICAgICBub3QgYmFja3dhcmQgY29tcGF0aWJsZS4NCj4gPg0KPiA+ICAgICBSZWdhcmRzDQo+ ID4NCj4gPiAgICAgRmVpDQo+ID4NCj4gPg0KPiA+ICAgICAqVmVybyBaaGVuZyA8dmVyby56aGVu Z0BodWF3ZWkuY29tDQo+IDxtYWlsdG86dmVyby56aGVuZ0BodWF3ZWkuY29tPj4qDQo+ID4NCj4g PiAgICAgMjAxMi0wMi0wNyAxNTozMw0KPiA+DQo+ID4NCj4gPiAgICAg5pS25Lu25Lq6DQo+ID4g ICAgIAkiemhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNu PiINCj4gPiAgICAgPHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRl LmNvbS5jbj4+DQo+ID4gICAgIOaKhOmAgQ0KPiA+ICAgICAJImNjYW1wQGlldGYub3JnIDxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2NhbXBAaWV0Zi5vcmcNCj4gPiAgICAgPG1haWx0bzpjY2Ft cEBpZXRmLm9yZz4+DQo+ID4gICAgIOS4u+mimA0KPiA+ICAgICAJUkU6IFtDQ0FNUF0gRGlzY3Vz c2lvbiBvbiBob3cgdG8gY2FycnkgdGhlIEdsb2JhbF9JRA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAgRmVpLA0KPiA+DQo+ID4gICAgIFBsZWFzZSBzZWUg aW4tbGluZS4NCj4gPg0KPiA+ICAgICBCUiwNCj4gPiAgICAgVmVybw0KPiA+DQo+ID4gICAgIEZl aSwNCj4gPg0KPiA+ICAgICB5b3Ugd3JvdGU6DQo+ID4NCj4gPiAgICAgRmlyc3QsDQo+ID4gICAg IOKAnDIuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2NhbXAtbXBscy10 cC1vaW8tMDENCj4gPg0KPiA+ICAgICBUaGUgR2xvYmFsX0lEIE9iamVjdCBhbmQgdGhlIElDQ19P cGVyYXRvcl9JRCBPYmplY3QgYXJlIGRlZmluZWQgaW4NCj4gPiAgICAgdGhpcyBkcmFmdCwgIHdo aWNoIGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJlIG9mIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwNCj4g PiAgICAgTFNQIChhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBjb3ZlcmVkIGlu IHRoZSBjdXJyZW50DQo+ID4gICAgIHZlcnNpb24pIGFuZCByZXF1aXJlcyB0aGF0IHRoZSBzYW1l IGZvcm1hdCggR2xvYmFsX0lEIG9yDQo+ID4gICAgIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkIGFs b25nIHRoZSBMU1AuDQo+ID4NCj4gPiAgICAgV2hpY2ggaXMgbm90IHRydWUuIFRoZSBPYmplY3Qg d2UgZGVmaW5lZCBjb3VsZCBiZSBjYXJyaWVkIGluIGJvdGgNCj4gPiAgICAgUGF0aC9SZXN2IG1l c3NhZ2UsIGFuZCBpcyBub3QgcmVzdHJpY3RlZCBlaXRoZXIgdG8gY28tcm91dGVkDQo+ID4gICAg IGJpLWRpcmVjdGlvbmFsIExTUCBvciBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIExTUC4NCj4g Pg0KPiA+ICAgICA8ZmVpPg0KPiA+ICAgICBBbHRob3VnaCBlaXRoZXIgY28tcm91dGVkIG9yIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgaXMgbm90DQo+ID4gICAgIG1lbnRpb25lZCBpbiB0 aGlzIGRyYWZ0ICwgYWNjb3JkaW5nIHRvICB0aGUgZGVzY3JpcGl0aW9uIGluIHNlY3Rpb24NCj4g PiAgICAgMi4zLCAiIElmIHRoZSBub2RlIGFncmVlcywgaXQgTVVTVCB1c2UgdGhlIHNhbWUgZm9y bWF0IG9mIE9wZXJhdG9yDQo+ID4gICAgIElELiAgVGhlIHNhbWUgQy1UeXBlIG9mIE9JTyBNVVNU IGJlIGNhcnJpZWQgaW4gdGhlIFJlc3YgbWVzc2FnZSIsDQo+ID4gICAgIHdoaWNoIG1lYW5zIHRo YXQgIHRoZSBwcm9jZWR1cmUgaXMgZm9yIGNvcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AuDQo+ID4g ICAgIFRoZSBhYm92ZSBpcyBqdXN0IG15IHVuZGVyc3RhbmRpbmcgYW5kIHByb3ZpZGVkIGZvciBk aXNjdXNzaW9uLCBhbmQNCj4gPiAgICAgaWYgaXQgaXMgd3Jvbmcgb3IgaW5hY2N1cmF0ZSwgcGxl YXNlIGxldCBtZSBrbm93Lg0KPiA+ICAgICA8L2ZlaT4NCj4gPiAgICAgVGhlIHByb2NlZHVyZSBk ZXNjcmliZWQgYWJvdmUgYWltcyB0byBndWFyYW50ZWUgdGhlIHNlbmRlciBhbmQgdGhlDQo+ID4g ICAgIHJlY2VpdmVyIHVzaW5nIHRoZSBzYW1lIEMtVHlwZSBvZiB0aGUgb2JqZWN0LCBpLmUuIGJv dGggZW5kIHVzaW5nDQo+ID4gICAgIEdsb2JhbF9JRCBvciBib3RoIHVzaW5nIElDQ19PcGVyYXRv cl9JRC4NCj4gPg0KPiA+ICAgICBTZWNvbmQsDQo+ID4gICAgIDMuDQo+ID4NCj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1 bm5lbC1udW0tMA0KPiAxDQo+ID4NCj4gPg0KPiA+ICAgICBUaGUgR2xvYmFsX0lEIGlzIGNhcnJp ZWQgYXMgYSBUTFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3aGljaA0KPiA+ICAgICB3 aWxsIGFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVjdGlv bmFsIExTUA0KPiA+ICAgICBhbmQgb25seSBhcHBlYXIgaW4gdGhlIFBhdGggbWVzc2FnZSBvZiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KPiA+ICAgICBGdXJ0aGVybW9yZSwgdGhpcyBk cmFmdCBkZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJyeSB0aGUNCj4gPiAgICAg bG9jYWwgdHVubmVsIG51bWJlciBhc3NpZ25lZCBhdCBaOSBub2RlcyBpbiB0aGUgc2NlbmFyaW8g b2YgY29yb3V0ZWQNCj4gPiAgICAgYmlkaXJlY3Rpb25hbCBMU1AuDQo+ID4NCj4gPiAgICAgV2h5 IOKAnHR1bm5lbCBudW1iZXLigJ0gaXMgY2FycmllZCBpbiB0aGUgQ29ubmVjdGlvbiBUTFY/IEkg ZG9uJ3Qgc2VlDQo+ID4gICAgIGl0cyBuZWNlc3NhcnkgZm9yIGJvdGggY28tcm91dGUvIGFzc29j aWF0ZWQgYmktZGlyZWN0aW9uYWwgTFNQLg0KPiA+ICAgICBDb3VsZCB5b3UgZXhwbGFpbj8NCj4g Pg0KPiA+ICAgICA8ZmVpPg0KPiA+ICAgICBBcyBJIHNhaWQsIGl0IGlzIHVzZWZ1bCBmb3IgY29y b3V0ZWQgKG5vdCBhc3NvY2lhdGVkKSBiaWRpcmVjdGlvbmFsDQo+ID4gICAgIExTUCwgIGNvbnNp ZGVyIHRoYXQgdGhlcmUgaXMgb25lIExTUCAoTFNQMSwgaW5pdGlhdGVkIGF0IG5vZGUgQSkNCj4g PiAgICAgYmV0d2VlbiBub2RlIEEvWi4NCj4gPiAgICAgSWYgdGhlIENDLVYgcGFrY2V0IGlzICBz ZW50IGZyb20gIG5vZGUgWiwgdGhlIE1FUF9JRCBvZiBub2RlIFogd2lsbA0KPiA+ICAgICBiZSBp bnNlcnRlZCBpbiB0aGUgT0FNIHBhY2tldHMsIHdoaWNoIGlzIG9yZ2FuaXplZCBieQ0KPiA+ICAg ICBub2RlX0lEOjp0dW5uZWxfbnVtOjpMU1BfbnVtDQo+ID4gICAgIChzZWN0aW9uIDUuMi4xIG9y IDcuMi4yIG9mIFJGQzYzNzApLCBhbmQgaWYgdGhpcyBNRVBfSUQgaXMgbm90DQo+ID4gICAgIHBy ZS1zdG9yZWQgYXQgbm9kZSBBLCBpdCBjYW4gbm90IGp1ZGdlIHdoZXRoZXIgdGhpcyBNRVBfSUQg aXMgdmFsaWQuDQo+ID4gICAgIFNlZSB0aGUgZGVzY3JpcHRpb24gaW4gc2VjdGlvbiA1LjEuMS4y DQo+ID4gICAgICgqTWlzLUNvbm5lY3Rpdml0eSBEZWZlY3QqKSBvZiBSRkM2MzcxLg0KPiA+ICAg ICAgICAgICAgICAgICAgICAgICBMU1AxDQo+ID4gICAgIEEtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tWg0KPiA+DQo+ID4NCj4gPiAgICAgPC9mZWk+DQo+ID4gICAgIFdoeSBpcyB0dW5u ZWwgbnVtYmVyIG5vdCBrbm93biBieSBub2RlIEE/IFRoZSB0dW5uZWwgbnVtYmVyIHNob3VsZA0K PiA+ICAgICBoYXMgYmVlbiBjYXJyaWVkIGluIFNlc3Npb24gYW5kIFNlbmRlciBUZW1wbGF0ZS9G aWx0ZXIgU3BlYyBvYmplY3QNCj4gPiAgICAgYW5kIGV4Y2hhbmdlZCBieSBub2RlIEEgYW5kIG5v ZGUgWiBkdXJpbmcgdGhlIExTUCBzZXQtdXAuIENvcnJlY3QgbWUNCj4gPiAgICAgaWYgSSBhbSB3 cm9uZy4NCj4gPg0KPiA+ICAgICBCUiwNCj4gPiAgICAgVmVybw0KPiA+DQo+ID4gICAgIFRoYW5r cy4NCj4gPg0KPiA+ICAgICBWZXJvDQo+ID4NCj4gPiAgICAgICoNCj4gPiAgICAgRnJvbToqIGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KPiA+ ICAgICBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnPl0NCj4gKk9uDQo+ID4gICAgIEJlaGFsZiBPZiAqemhhbmcuZmVpM0B6dGUuY29t LmNuIDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPioNCj4gPiAgICAgU2VudDoqIFN1bmRh eSwgSmFudWFyeSAyOSwgMjAxMiA1OjUwIFBNKg0KPiA+ICAgICBUbzoqIGNjYW1wQGlldGYub3Jn IDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+Kg0KPiA+ICAgICBTdWJqZWN0OiogW0NDQU1QXSBEaXNj dXNzaW9uIG9uIGhvdyB0byBjYXJyeSB0aGUgR2xvYmFsX0lEDQo+ID4NCj4gPg0KPiA+ICAgICBI aSBDQ0FNUGVycw0KPiA+DQo+ID4gICAgIEFzIGRpc2N1c3NlZCBpbiB0aGUgbGFzdCBJRVRGIG1l ZXRpbmcgYW5kIG1haWxpbmdsaXN0LCB0aGUgR2xvYmFsX0lEDQo+ID4gICAgIHNob3VsZCBiZSBj YXJyaWVkIGluIHRoZSBzaWduYWxpbmcgbWVzc2FnZXMuIE9uZSByZWFzb24gaXMgdGhhdCB0aGUN Cj4gPiAgICAganVkZ2VtZW50IG9mIGEgbWlzLWNvbm5lY3Rpdml0eSBkZWZlY3QgbmVlZHMgdGhl IEExL1o5IG5vZGVzIHRvDQo+ID4gICAgIHByZS1zdG9yZSBlYWNoIG90aGVyJ3MgTUVQX0lELCB3 aG9zZSBmb3JtYXQgaXM6DQo+ID4gICAgIEdvYmFsX0lEK05vZGVfSUQrVHVubmVsX251bStMU1Bf bnVtLg0KPiA+DQo+ID4gICAgIEZvcnR1bmF0ZWx5LCB0aGVyZSBhcmUgc2V2ZXJhbCBkcmFmdHMg cmVsYXRlZCB0byB0aGlzIHRvcGljIG5vdywNCj4gPg0KPiA+ICAgICAxLiAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDEuDQo+ID4NCj4gPiAg ICAgVGhlIEdsb2JhX0lEIGlzIGluY29ycG9yYXRlZCBpbnRvIHRoZSBBU1NPQ0lBVElPTiBvYmpl Y3QgaW4gdGhlDQo+ID4gICAgIGN1cnJlbnQgdmVyc2lvbiwgd2hpY2ggZ3VhcmFudGVlcyB0aGF0 IHRoZSBhc3NvY2lhdGlvbiBpcyBnbG9iYWwNCj4gPiAgICAgdW5pcXVlLiBTaW5jZSB0aGUgQVNT T0NJQVRJT04gb2JqZWN0IGlzIHVzZWQgYWNyb3NzIGRpZmZlcmVudCBMU1BzLA0KPiA+ICAgICBq dXN0IG15MmNlbnRzLCB0aGUgZGVmaW5lZCBmb3JtYXQgaXMgZGVmaWNpZW50IHRvIGhhbmRsZSBt b3JlDQo+ID4gICAgIHNjZW5hcmlvcy4gRm9yIGV4YW1wbGU6DQo+ID4NCj4gPiAgICAgICAoMSkg Q29uc2lkZXJpbmcgYSBjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgd2hpY2ggaXMgbm90DQo+ ID4gICAgIHByb3RlY3RlZCBieSBvdGhlciBMU1BzIHRocm91Z2ggY29udHJvbCBwbGFuZSBhbmQv b3IgZG9lcyBub3Qgc2hhcmUNCj4gPiAgICAgdGhlIHNhbWUgcmVzb3VyZXMgd2l0aCBvdGhlciBM U1BzLiBJbiB0aGVzZSBjYXNlcywgdGhlIEFTU09DSUFUSU9ODQo+ID4gICAgIG9iamVjdCB3aWxs IG5vdCBiZSBjYXJyaWVkIGluIHRoZSBzaWdhbGluZyBtZXNzYWdlcy4NCj4gPg0KPiA+ICAgICAg ICgyKSBDb25zaWRlcmluZyBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLCBhbHRob3Vn aCB0aGUNCj4gPiAgICAgQVNTT0NJQVRJT04gb2JqZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2Fs aW5nIG1lc3NhZ2VzLCB0aGUNCj4gPiAgICAgZ2xvYmFsX0lEIGluY29ycG9yYXRlZCBpbiB0aGUg QVNTT0NJQVRJT04gb2JqZWN0IG9ubHkNCj4gPiAgICAgaW5kaWNhdGVzIHRoZSBnbG9iYWwgcHJl Zml4IG9mIHRoZSBBMSBvciBaOSBub2Rlcy4gSWYgdGhpcyBMU1AgaXMNCj4gPiAgICAgYWNyb3Nz IGRpZmZlcmVudCBkb21haW5zLCBJIHRoaW5rIHRoZSBjdXJyZW50IGZvcm1hdCBpcyBhbHNvDQo+ ID4gICAgIGRlZmljaWVudCAoQTEgZG9lcyBub3Qga25vdyB0aGUgZ29iYWwgSUQgb2YgWjkgbm9k ZSBvciBaOSBub2RlcyBkb2VzDQo+ID4gICAgIG5vdCBrbm93IHRoZSBnbG9iYWwgSUQgb2YgQTEg KS4NCj4gPg0KPiA+ICAgICAyLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVu LWNjYW1wLW1wbHMtdHAtb2lvLTAxDQo+ID4NCj4gPiAgICAgVGhlIEdsb2JhbF9JRCBPYmplY3Qg YW5kIHRoZSBJQ0NfT3BlcmF0b3JfSUQgT2JqZWN0IGFyZSBkZWZpbmVkIGluDQo+ID4gICAgIHRo aXMgZHJhZnQsICB3aGljaCBkZXNjcmliZXMgdGhlIHByb2NlZHVyZSBvZiBjb3JvdXRlZCBiaWRp cmVjdGlvbmFsDQo+ID4gICAgIExTUCAoYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBpcyBu b3QgY292ZXJlZCBpbiB0aGUgY3VycmVudA0KPiA+ICAgICB2ZXJzaW9uKSBhbmQgcmVxdWlyZXMg dGhhdCB0aGUgc2FtZSBmb3JtYXQoIEdsb2JhbF9JRCBvcg0KPiA+ICAgICBJQ0NfT3BlcmF0b3Jf SUQpaXMgdXNlZCBhbG9uZyB0aGUgTFNQLg0KPiA+DQo+ID4gICAgIDMuDQo+ID4NCj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LXR1bm5lbC1udW0tMA0KPiAxDQo+ID4NCj4gPg0KPiA+ICAgICBUaGUgR2xvYmFsX0lEIGlzIGNh cnJpZWQgYXMgYSBUTFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3aGljaA0KPiA+ICAg ICB3aWxsIGFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVj dGlvbmFsIExTUA0KPiA+ICAgICBhbmQgb25seSBhcHBlYXIgaW4gdGhlIFBhdGggbWVzc2FnZSBv ZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KPiA+ICAgICBGdXJ0aGVybW9yZSwgdGhp cyBkcmFmdCBkZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJyeSB0aGUNCj4gPiAg ICAgbG9jYWwgdHVubmVsIG51bWJlciBhc3NpZ25lZCBhdCBaOSBub2RlcyBpbiB0aGUgc2NlbmFy aW8gb2YgY29yb3V0ZWQNCj4gPiAgICAgYmlkaXJlY3Rpb25hbCBMU1AuDQo+ID4NCj4gPg0KPiA+ ICAgICBUaGUgYWJvdmUgbWF0ZXJpYWxzIG9ubHkgcHJvdmlkZSB0aGUgcm91Z2ggYmFja2dyb3Vu ZC4NCj4gPg0KPiA+DQo+ID4gICAgIEhvcGUgdG8gaGVhciB0aGUgb3BpbmlvbnMgZnJvbSB0aGUg V0cgdGhhdCBob3cgdG8gY2FycnkgdGhlDQo+ID4gICAgIEdsb2JhbF9JRCwgdGhlbiBtb3ZlIHRo ZSB3b3JrIGZvcndhcmQuDQo+ID4NCj4gPg0KPiA+ICAgICBCZXN0IHJlZ2FyZHMNCj4gPg0KPiA+ ICAgICA7KQ0KPiA+DQo+ID4gICAgIEZlaQ0KPiA+DQo+ID4gICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgIENDQU1QIG1haWxpbmcgbGlz dA0KPiA+ICAgICBDQ0FNUEBpZXRmLm9yZyA8bWFpbHRvOkNDQU1QQGlldGYub3JnPg0KPiA+ICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ID4NCj4gPg0K PiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IENDQU1QIG1haWxpbmcgbGlzdA0KPiA+IENDQU1QQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QN Cj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0K From lizhong.jin@zte.com.cn Tue Feb 7 18:26: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 3A04711E8080 for ; Tue, 7 Feb 2012 18:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.909 X-Spam-Level: X-Spam-Status: No, score=-100.909 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HTYq-a+wdupn for ; Tue, 7 Feb 2012 18:26:07 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD5A1F0C38 for ; Tue, 7 Feb 2012 18:25:49 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 53829806486374; Wed, 8 Feb 2012 10:20:56 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.6407659339; Wed, 8 Feb 2012 10:25:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q182PfSC013452; Wed, 8 Feb 2012 10:25:41 +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: Wed, 8 Feb 2012 10:24:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 10:25:42, Serialize complete at 2012-02-08 10:25:42 Content-Type: multipart/alternative; boundary="=_alternative 000D56D24825799E_=" X-MAIL: mse02.zte.com.cn q182PfSC013452 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: Wed, 08 Feb 2012 02:26:09 -0000 This is a multipart message in MIME format. --=_alternative 000D56D24825799E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UHJhbmphbCwNClNlZSBpbmxpbmUgYmVsb3cuDQoNClRoYW5rcw0KTGl6aG9uZw0KIA0KDQoiRHV0 dGEsIFByYW5qYWwgSyAoUHJhbmphbCkiIDxwcmFuamFsLmR1dHRhQGFsY2F0ZWwtbHVjZW50LmNv bT4gd3JvdGUgDQoyMDEyLzAyLzA4IDAyOjQwOjMxOg0KDQo+IEhpLA0KPiAgICAgICBVc2luZyBz ZXBhcmF0ZSBhZGphY2VuY3kgdG8gZGVjaWRlIGNhcGFiaWxpdGllcyBvbiBhbiANCj4gaW50ZXJm YWNlIHdvdWxkIGtpY2sgc3RhcnQgc2V2ZXJhbCB3YXJzIGFzIHRoZSBpc3N1ZSBub3QganVzdCAN Cj4gbGltaXRlZCB0byBJUFY0IHZzIElQVjYuIFRoZSBzYW1lIGlzIGFwcGxpY2FibGUgdG8gbXVs dGljYXN0IA0KPiBjYXBhYmlsaXRpZXMgYXMgd2VsbCB3aGVuIGFuIG9wZXJhdG9yIG1heSBoYXZl IG11bHRpcGxlIEVDTVAgbGlua3MgDQo+IGJldHdlZW4gdHdvIG5vZGVzIGJ1dCBjZXJ0YWluIGxp bmtzL2NhcmRzIGRvIG5vdCBoYXZlIG11bHRpY2FzdCANCj4gY2FwYWJpbGl0aWVzLiANCltMaXpo b25nXSBUaGVvcmV0aWNhbGx5LCB5b3UgYXJlIHJpZ2h0LiBBbmQgdXN1c2FsbHkgd2UgYXNzdW1l IExEUCBlbmFibGVkIA0KaW50ZXJmYWNlIGFsc28gc3VwcG9ydCBtdWx0aWNhc3QgaWYgTERQIHNl c3Npb24gaXMgbXVsdGljYXN0IGVuYWJsZWQsIGJ1dCANCnllcywgc3VjaCBhc3N1bXB0aW9uIGhh cyByaXNrLg0KDQo+IFRoaXMgaXMganVzdCBvbmUgZXhhbXBsZSBhbmQgd2UgaGF2ZSBtb3JlIHN1 Y2ggDQo+IGNhcGFiaWl0aWVzLiBTbyBhcyBvZiBub3cgc3VjaCBsaW5rIHNwZWNpZmljIHJlc3Ry aWN0aW9ucyBzaG91bGQgYmUgDQo+IGltcG9zZWQgYnkgbG9jYWwgYmVoYXZpb3JzIHJhdGhlciB0 aGFuIGNvdXBsaW5nIHdpdGggYWRqYWNlbmN5IA0KPiB0eXBlcy4gDQpbTGl6aG9uZ10gUmVzdHJp Y3Rpb24gY2hlY2tpbmcgYmFzZWQgb24gbG9jYWwgY2FwYWJpbGl0eSBpcyBub3QgZW5vdWdoLCAN CmFuZCBoYXZpbmcgY2FwYWJpbGl0eSByaXNrIG9mIHBlZXIgaW50ZXJmYWNlLg0KDQo+IE90aGVy d2lzZSBMRFAgY2FwYWJpbGl0aWVzIHNob3VsZCBiZSBleHRlbmRlZCB0byBiZSB1c2VkIGluIA0K PiBwZXIgaW50ZXJmYWNlIGxkcCBoZWxsbyBtZXNzYWdlcyB3aGVyZSBhIHNpbmdsZSBhZGphY2Vu Y3kgd291bGQgYmUgDQo+IHRhZ2dlZCBtdWx0aXBsZSBjYXBhYmlsaXRpZXMuIA0KW0xpemhvbmdd IExEUCBjYXBhYmlsaXR5IGJhc2VkIG9uIHBlciBhZGphY2VuY3kgaXMgYSBmZWFzaWJsZSBhcHBy b2FjaCwgDQphbmQgaWYgdGhhdCwgd2UgbmVlZCB0byBjaGFuZ2UgUkZDNTU2MS4NCg0KPiBJIHdv dWxkIGJlbGlldmUgdGhhdCBpcyBtb3JlIHJpZ2h0ZnVsIA0KPiBhcHByb2FjaCB0aGFuIG1haW50 YWluaW5nIHNlcGFyYXRlIGhlbGxvcyBhZGphY2VuY2llcyBmb3IgZWFjaCANCj4gY2FwYWJpbGl0 eSB0aGF0IHdvdWxkIGdyb3cgZXhwb25lbnRpYWxseSBhdCBzb21lIHBvaW50LiANCj4gDQo+IFRo YW5rcywNCj4gUHJhbmphbA0KPiANCj4gDQo+IA0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4gS2FtcmFu IFJhemENCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAwNiwgMjAxMiA4OjUwIFBNDQo+IFRvOiBM aXpob25nIEppbjsgRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCk7IHZpc2h3YXMuaWV0ZkBnbWFp bC5jb207DQo+IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpDQo+IENjOiBtcGxzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxk cC1pcHY2LTA2DQo+IA0KPiBIaSBMaXpob25nLA0KPiANCj4gVXNpbmcgc2luZ2xlIGFkaiBbIGFu ZCBqdXN0IGNoZWNraW5nIGxvY2FsIGludGVyZmFjZSBlbmFibGluZyBmb3IgDQo+IGdpdmVuIEFG ICsgY2FwYWJpbGl0aWVzIF0gd2lsbCBub3Qgc3VmZmljZS93b3JrIGJlY2F1c2U6DQo+IA0KPiAg MS4gTERQIGNhcGFiaWxpdGllcyBhcmUgYWR2ZXJ0aXNlZCBvbiBwZWVyL3Nlc3Npb24gbGV2ZWwg YW5kIGRvIG5vdA0KPiBjb3JyZXNwb25kIHRvIGFkaiBjYXBhYmlsaXRpZXMuDQo+ICAyLiBBbiBM U1IgbXVzdCBub3QgYmUgZm9yd2FyZGluZyBNUExTIG9uIGFuIGludGVyZmFjZSB1bmxlc3MvdW50 aWwgDQo+IGl0IGhhcyBnb3QgYW4gTVBMUyBhZGogb24gaXQgqEMgZXh0ZW5kaW5nIHRoZSBzYW1l IHRvIGFkZHJlc3MgDQo+IGZhbWlsaWVzLCBhbiBMU1IgbXVzdCBub3QgZm9yd2FyZCBNUExTIHY2 IG9uIGFuIGludGVyZmFjZSB1bmxlc3MgaXQgDQo+IGhhcyBnb3QgTVBMUyB2NiBhZGogb24gaXQu IFsgU2luZ2xlIGFkaiB3aWxsIG5vdCBjb252ZXkgdXMgcmVtb3RlIA0KPiBub2Rloa9zIGludGVy ZmFjZSBjYXBhYmlsaXR5IGZvciBnaXZlbiBBRiwgYW5kIGl0IHdpbGwgYmUgaW5jb3JyZWN0IA0K PiB0byBmb3J3YXJkIDYgTVBMUyBsYWJlbGxlZCB0cmFmZmljIG9uIGl0IHVubGVzcyB3ZSBrbm93 IHRoYXQgcmVtb3RlIA0KPiBpbnRmIGlzIHY2IE1QTFMgZW5hYmxlZCBdDQo+IA0KPiAgTXkgMiBj ZW50cy4NCj4gLS0gS2FtcmFuDQo+IA0KPiBPbiAxMi0wMi0wNiAxMDoyMiBQTSwgIkxpemhvbmcg SmluIiA8bGl6aG9uZy5qaW5AenRlLmNvbS5jbj4gd3JvdGU6DQo+IA0KPiBIaSwgDQo+IEkgd29u ZGVyIGlmIGl0IGlzIGZlYXNpYmxlIHRvIHVzZSBMRFAgY2FwYWJpbGl0eSB0byBhZHZlcnRpc2Ug SVB2NiANCj4gRkVDIHdpdGhvdXQgSVB2NiBhZGphY2VuY3ksIGFuZCBvbmx5IHVzZSBvbmUgYWRq YWNlbmN5IGZvciBMRFAgDQo+IHNlc3Npb24gaW4gZHVhbC1zdGFjayBuZXR3b3JrLiBMRFAgY2Fw YWJpbGl0eSBpcyBwZXIgbm9kZSANCj4gY2FwYWJpbGl0eSwgbm90IHBlciBpbnRlcmZhY2UgY2Fw YWJpbGl0eS4gQnV0IGZvciBMRFAgdG8gY2hvb3NlIHRoZSANCj4gY29ycmVjdCBkb3duc3RyZWFt IHNlc3Npb24gYW5kIG91dHB1dCBpbnRlcmZhY2UgZm9yIGVhY2ggRkVDLCBpdCANCj4gc2hvdWxk IGFsc28gY2hlY2sgaWYgdGhlIG91dHB1dCBpbnRlcmZhY2UgaXMgTERQIGVuYWJsZWQgb3Igbm90 LiBUaGUNCj4gbGluayBhZGphY2VuY3kgY291bGQgYmUgdXNlZCB0byBhc3Npc3Qgc3VjaCBraW5k IG9mIGNoZWNraW5nLiANCj4gDQo+IFtLYW1yYW5dOg0KPiANCj4gSG93ZXZlciwgSU1PLCBpdCBp cyB2YWx1YWJsZSB0byBhbGxvdyB0d28gaW5kZXBlbmRlbnQgTERQIHNlc3Npb25zIA0KPiBmb3Ig SVB2NCBhbmQgSVB2NiBhcyBhbiBvcHRpb24uIFJlZ2FyZGluZyB0aGUgZm9ybWF0IGRlZmluaXRp b24gaW4gDQo+IFJGQzUwMzYsIHdlIG1heSBuZWVkIG5ldyBMRFAgdmVyc2lvbiBudW1iZXIgdG8g aWRlbnRpZnkgSVB2NiBMU1ItSUQuDQo+IE9yIHdlIHVzZSBkaWZmZXJlbnQgMzJiaXQgTFNSLUlE IGZvciBJUHY2IHdpdGggSVB2NCwgYnV0IEkgcHJlZmVyIA0KPiBuZXcgZm9ybWF0IG9mIExTUi1J RC4gDQo+IA0KPiBSZWdhcmRzIA0KPiBMaXpob25nIA0KPiANCj4gDQo+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+IA0KPiA+IE1lc3NhZ2U6IDENCj4gPiBEYXRlOiBUdWUsIDcgRmViIDIwMTIgMDU6Mjg6 MjEgKzA1MzANCj4gPiBGcm9tOiAiRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCkiIDxwcmFuamFs LmR1dHRhQGFsY2F0ZWwtbHVjZW50LmNvbT4NCj4gPiBUbzogVmlzaHdhcyBNYW5yYWwgPHZpc2h3 YXMuaWV0ZkBnbWFpbC5jb20+DQo+ID4gQ2M6ICJBaXNzYW91aSwgTXVzdGFwaGEgXChNdXN0YXBo YVwpIg0KPiA+ICAgIDxtdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+LCAgIm1w bHNAaWV0Zi5vcmciDQo+ID4gICAgPG1wbHNAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFtt cGxzXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYtMDYNCj4gPiBNZXNzYWdl LUlEOg0KPiA+ICAgIDxDNTg0MDQ2NDY2RUQyMjRDQTkyQzFCQzMzMTNCOTYzRTA5RUZFOEQ2NjdA SU5CQU5TWENITUJTQTMuaW4uDQo+ID4gYWxjYXRlbC1sdWNlbnQuY29tPg0KPiA+IA0KPiA+IENv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+ID4gDQo+ID4gSSB3 b3VsZCByYXRoZXIgZm9yIGNvbXBsZXRlIHNlcGFyYXRpb24gd2l0aCBtdWx0aXBsZSBsc3ItaWQg YmVjYXVzZSANCj4gPiBoYXZpbmcgc2VwYXJhdGUgbGluayBhZGphY2VuY2llcyBkb2VzIG5vdCBy ZWFsbHkgc29sdmVkIGFueSBwcm9ibGVtLg0KPiA+IFNpbmNlIGhlbGxvIGFkamFjZW5jaWVzIGFy ZSBhc3NvY2lhdGVkIHdpdGggYSBsaW5rLCBzdGlsbCBmYXRlIA0KPiA+IHNoYXJpbmcgd291bGQg Y29udGludWUgb3ZlciB0aGUgc2luZ2xlIGxkcC90Y3Agc2Vzc2lvbiBmb3IgSVBWNCBhbmQgDQpJ UFY2Lg0KPiA+IEhhdmluZyBJUFY0IGFuZCBJUFY2IHNwZWNpZmljIGhlbGxvIGFkamFjZW5jaWVz IG92ZXIgYSBsaW5rIHdvdWxkIA0KPiA+IG9ubHkgZGVjaWRlIHdoZXRoZXIgc3VjaCBhIGxpbmsg aXMgdG8gYmUgcHJvZ3JhbW1lZCBmb3IgSVBWNCBvciBJUFY2DQo+ID4gZWdyZXNzIHRyYWZmaWMg YnV0IEkgc2VlIGl0IGFzIG92ZXJraWxsIGFuZCB1bm5lY2Vzc2FyeSBzY2FsYWJpbGl0eSANCmlt cGFjdHMuDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IFByYW5qYWwNCj4gPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGlu ZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzDQo+IA0KPiAtLSANCj4gU3llZCBLYW1yYW4gUmF6YQ0KPiBUZWNobmljYWwg TGVhZGVyLCBTUFJTRyBJT1MtWFIgUm91dGluZyAoTVBMUykNCj4gQ2lzY28gU3lzdGVtcywgSW5j LiwgDQo+IEthbmF0YSwgT04sIEsySyAzRTgsIENhbmFkYSANCj4gUGg6ICsxICg2MTMpIDI1NC00 NTIwDQo+IGh0dHA6Ly93d3cuY2lzY28uY29tIA0KPiANCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 000D56D24825799E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlByYW5qYWwsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TZWUgaW5saW5lIGJlbG93LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5MaXpob25nPC9mb250Pg0KPGJyPjxm b250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9Mj48dHQ+JnF1b3Q7RHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCkmcXVvdDsgJmx0O3ByYW5q YWwuZHV0dGFAYWxjYXRlbC1sdWNlbnQuY29tJmd0Ow0Kd3JvdGUgMjAxMi8wMi8wOCAwMjo0MDoz MTo8YnI+DQo8YnI+DQomZ3Q7IEhpLDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBVc2luZyBzZXBhcmF0ZSBhZGphY2VuY3kNCnRvIGRl Y2lkZSBjYXBhYmlsaXRpZXMgb24gYW4gPGJyPg0KJmd0OyBpbnRlcmZhY2Ugd291bGQga2ljayBz dGFydCBzZXZlcmFsIHdhcnMgYXMgdGhlIGlzc3VlIG5vdCBqdXN0IDxicj4NCiZndDsgbGltaXRl ZCB0byBJUFY0IHZzIElQVjYuIFRoZSBzYW1lIGlzIGFwcGxpY2FibGUgdG8gbXVsdGljYXN0IDxi cj4NCiZndDsgY2FwYWJpbGl0aWVzIGFzIHdlbGwgd2hlbiBhbiBvcGVyYXRvciBtYXkgaGF2ZSBt dWx0aXBsZSBFQ01QIGxpbmtzDQo8YnI+DQomZ3Q7IGJldHdlZW4gdHdvIG5vZGVzIGJ1dCBjZXJ0 YWluIGxpbmtzL2NhcmRzIGRvIG5vdCBoYXZlIG11bHRpY2FzdCA8YnI+DQomZ3Q7IGNhcGFiaWxp dGllcy4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5bTGl6aG9uZ10gVGhlb3Jl dGljYWxseSwgeW91IGFyZSByaWdodC4gQW5kIHVzdXNhbGx5DQp3ZSBhc3N1bWUgTERQIGVuYWJs ZWQgaW50ZXJmYWNlIGFsc28gc3VwcG9ydCBtdWx0aWNhc3QgaWYgTERQIHNlc3Npb24gaXMNCm11 bHRpY2FzdCBlbmFibGVkLCBidXQgeWVzLCBzdWNoIGFzc3VtcHRpb24gaGFzIHJpc2suPC90dD48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFRoaXMgaXMganVzdCBvbmUg ZXhhbXBsZSBhbmQgd2UgaGF2ZSBtb3JlIHN1Y2gNCjxicj4NCiZndDsgY2FwYWJpaXRpZXMuIFNv IGFzIG9mIG5vdyBzdWNoIGxpbmsgc3BlY2lmaWMgcmVzdHJpY3Rpb25zIHNob3VsZCBiZQ0KPGJy Pg0KJmd0OyBpbXBvc2VkIGJ5IGxvY2FsIGJlaGF2aW9ycyByYXRoZXIgdGhhbiBjb3VwbGluZyB3 aXRoIGFkamFjZW5jeSA8YnI+DQomZ3Q7IHR5cGVzLiA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0PltMaXpob25nXSBSZXN0cmljdGlvbiBjaGVja2luZyBiYXNlZCBvbiBsb2NhbCBj YXBhYmlsaXR5DQppcyBub3QgZW5vdWdoLCBhbmQgaGF2aW5nIGNhcGFiaWxpdHkgcmlzayBvZiBw ZWVyIGludGVyZmFjZS48L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZn dDsgT3RoZXJ3aXNlIExEUCBjYXBhYmlsaXRpZXMgc2hvdWxkIGJlIGV4dGVuZGVkDQp0byBiZSB1 c2VkIGluIDxicj4NCiZndDsgcGVyIGludGVyZmFjZSBsZHAgaGVsbG8gbWVzc2FnZXMgd2hlcmUg YSBzaW5nbGUgYWRqYWNlbmN5IHdvdWxkIGJlDQo8YnI+DQomZ3Q7IHRhZ2dlZCBtdWx0aXBsZSBj YXBhYmlsaXRpZXMuIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+W0xpemhvbmdd IExEUCBjYXBhYmlsaXR5IGJhc2VkIG9uIHBlciBhZGphY2VuY3kgaXMNCmEgZmVhc2libGUgYXBw cm9hY2gsIGFuZCBpZiB0aGF0LCB3ZSBuZWVkIHRvIGNoYW5nZSBSRkM1NTYxLjwvdHQ+PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBJIHdvdWxkIGJlbGlldmUgdGhhdCBp cyBtb3JlIHJpZ2h0ZnVsIDxicj4NCiZndDsgYXBwcm9hY2ggdGhhbiBtYWludGFpbmluZyBzZXBh cmF0ZSBoZWxsb3MgYWRqYWNlbmNpZXMgZm9yIGVhY2ggPGJyPg0KJmd0OyBjYXBhYmlsaXR5IHRo YXQgd291bGQgZ3JvdyBleHBvbmVudGlhbGx5IGF0IHNvbWUgcG9pbnQuIDwvdHQ+PC9mb250Pg0K PGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0PiZndDsgVGhhbmtzLDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ Jmd0OyBQcmFuamFsPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAm bmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBG cm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KT2YgPGJyPg0KJmd0OyBLYW1yYW4gUmF6YTxicj4NCiZndDsgU2VudDogTW9u ZGF5LCBGZWJydWFyeSAwNiwgMjAxMiA4OjUwIFBNPGJyPg0KJmd0OyBUbzogTGl6aG9uZyBKaW47 IER1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpOyB2aXNod2FzLmlldGZAZ21haWwuY29tOzxicj4N CiZndDsgQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk8YnI+DQomZ3Q7IENjOiBtcGxzQGll dGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtbXBscy1sZHAtaXB2Ni0wNjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0 OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgSGkgTGl6aG9u Zyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVXNpbmcgc2luZ2xlIGFkaiBbIGFuZCBqdXN0IGNoZWNr aW5nIGxvY2FsIGludGVyZmFjZSBlbmFibGluZyBmb3INCjxicj4NCiZndDsgZ2l2ZW4gQUYgKyBj YXBhYmlsaXRpZXMgXSB3aWxsIG5vdCBzdWZmaWNlL3dvcmsgYmVjYXVzZTo8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJm5ic3A7MS4gTERQIGNhcGFiaWxpdGllcyBhcmUgYWR2ZXJ0aXNlZCBvbiBwZWVy L3Nlc3Npb24gbGV2ZWwgYW5kDQpkbyBub3Q8YnI+DQomZ3Q7IGNvcnJlc3BvbmQgdG8gYWRqIGNh cGFiaWxpdGllcy48YnI+DQomZ3Q7ICZuYnNwOzIuIEFuIExTUiBtdXN0IG5vdCBiZSBmb3J3YXJk aW5nIE1QTFMgb24gYW4gaW50ZXJmYWNlIHVubGVzcy91bnRpbA0KPGJyPg0KJmd0OyBpdCBoYXMg Z290IGFuIE1QTFMgYWRqIG9uIGl0IKhDIGV4dGVuZGluZyB0aGUgc2FtZSB0byBhZGRyZXNzIDxi cj4NCiZndDsgZmFtaWxpZXMsIGFuIExTUiBtdXN0IG5vdCBmb3J3YXJkIE1QTFMgdjYgb24gYW4g aW50ZXJmYWNlIHVubGVzcyBpdA0KPGJyPg0KJmd0OyBoYXMgZ290IE1QTFMgdjYgYWRqIG9uIGl0 LiBbIFNpbmdsZSBhZGogd2lsbCBub3QgY29udmV5IHVzIHJlbW90ZQ0KPGJyPg0KJmd0OyBub2Rl oa9zIGludGVyZmFjZSBjYXBhYmlsaXR5IGZvciBnaXZlbiBBRiwgYW5kIGl0IHdpbGwgYmUgaW5j b3JyZWN0DQo8YnI+DQomZ3Q7IHRvIGZvcndhcmQgNiBNUExTIGxhYmVsbGVkIHRyYWZmaWMgb24g aXQgdW5sZXNzIHdlIGtub3cgdGhhdCByZW1vdGUNCjxicj4NCiZndDsgaW50ZiBpcyB2NiBNUExT IGVuYWJsZWQgXTxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDtNeSAyIGNlbnRzLjxicj4NCiZn dDsgLS0gS2FtcmFuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDEyLTAyLTA2IDEwOjIyIFBNLCAm cXVvdDtMaXpob25nIEppbiZxdW90OyAmbHQ7bGl6aG9uZy5qaW5AenRlLmNvbS5jbiZndDsNCndy b3RlOjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IEhp LCA8YnI+DQomZ3Q7IEkgd29uZGVyIGlmIGl0IGlzIGZlYXNpYmxlIHRvIHVzZSBMRFAgY2FwYWJp bGl0eSB0byBhZHZlcnRpc2UgSVB2Ng0KPGJyPg0KJmd0OyBGRUMgd2l0aG91dCBJUHY2IGFkamFj ZW5jeSwgYW5kIG9ubHkgdXNlIG9uZSBhZGphY2VuY3kgZm9yIExEUCA8YnI+DQomZ3Q7IHNlc3Np b24gaW4gZHVhbC1zdGFjayBuZXR3b3JrLiBMRFAgY2FwYWJpbGl0eSBpcyBwZXIgbm9kZSA8YnI+ DQomZ3Q7IGNhcGFiaWxpdHksIG5vdCBwZXIgaW50ZXJmYWNlIGNhcGFiaWxpdHkuIEJ1dCBmb3Ig TERQIHRvIGNob29zZSB0aGUNCjxicj4NCiZndDsgY29ycmVjdCBkb3duc3RyZWFtIHNlc3Npb24g YW5kIG91dHB1dCBpbnRlcmZhY2UgZm9yIGVhY2ggRkVDLCBpdCA8YnI+DQomZ3Q7IHNob3VsZCBh bHNvIGNoZWNrIGlmIHRoZSBvdXRwdXQgaW50ZXJmYWNlIGlzIExEUCBlbmFibGVkIG9yIG5vdC4g VGhlPGJyPg0KJmd0OyBsaW5rIGFkamFjZW5jeSBjb3VsZCBiZSB1c2VkIHRvIGFzc2lzdCBzdWNo IGtpbmQgb2YgY2hlY2tpbmcuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBbS2FtcmFuXTo8YnI+DQom Z3Q7IDxicj4NCiZndDsgSG93ZXZlciwgSU1PLCBpdCBpcyB2YWx1YWJsZSB0byBhbGxvdyB0d28g aW5kZXBlbmRlbnQgTERQIHNlc3Npb25zDQo8YnI+DQomZ3Q7IGZvciBJUHY0IGFuZCBJUHY2IGFz IGFuIG9wdGlvbi4gUmVnYXJkaW5nIHRoZSBmb3JtYXQgZGVmaW5pdGlvbiBpbg0KPGJyPg0KJmd0 OyBSRkM1MDM2LCB3ZSBtYXkgbmVlZCBuZXcgTERQIHZlcnNpb24gbnVtYmVyIHRvIGlkZW50aWZ5 IElQdjYgTFNSLUlELjxicj4NCiZndDsgT3Igd2UgdXNlIGRpZmZlcmVudCAzMmJpdCBMU1ItSUQg Zm9yIElQdjYgd2l0aCBJUHY0LCBidXQgSSBwcmVmZXINCjxicj4NCiZndDsgbmV3IGZvcm1hdCBv ZiBMU1ItSUQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzIDxicj4NCiZndDsgTGl6aG9u ZyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE1lc3NhZ2U6IDE8YnI+DQomZ3Q7ICZndDsgRGF0 ZTogVHVlLCA3IEZlYiAyMDEyIDA1OjI4OjIxICswNTMwPGJyPg0KJmd0OyAmZ3Q7IEZyb206ICZx dW90O0R1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpJnF1b3Q7ICZsdDtwcmFuamFsLmR1dHRhQGFs Y2F0ZWwtbHVjZW50LmNvbSZndDs8YnI+DQomZ3Q7ICZndDsgVG86IFZpc2h3YXMgTWFucmFsICZs dDt2aXNod2FzLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCiZndDsgJmd0OyBDYzogJnF1b3Q7QWlz c2FvdWksIE11c3RhcGhhIFwoTXVzdGFwaGFcKSZxdW90Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7Jmx0O211c3RhcGhhLmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbSZndDssICZuYnNw OyZxdW90O21wbHNAaWV0Zi5vcmcmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyZs dDttcGxzQGlldGYub3JnJmd0Ozxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIENv bW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0wNjxicj4NCiZndDsgJmd0OyBNZXNz YWdlLUlEOjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Jmx0O0M1ODQwNDY0NjZFRDIyNENB OTJDMUJDMzMxM0I5NjNFMDlFRkU4RDY2N0BJTkJBTlNYQ0hNQlNBMy5pbi48YnI+DQomZ3Q7ICZn dDsgYWxjYXRlbC1sdWNlbnQuY29tJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7PGJy Pg0KJmd0OyAmZ3Q7IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0mcXVvdDt1cy1h c2NpaSZxdW90Ozxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSB3b3VsZCByYXRoZXIg Zm9yIGNvbXBsZXRlIHNlcGFyYXRpb24gd2l0aCBtdWx0aXBsZSBsc3ItaWQgYmVjYXVzZQ0KPGJy Pg0KJmd0OyAmZ3Q7IGhhdmluZyBzZXBhcmF0ZSBsaW5rIGFkamFjZW5jaWVzIGRvZXMgbm90IHJl YWxseSBzb2x2ZWQgYW55IHByb2JsZW0uPGJyPg0KJmd0OyAmZ3Q7IFNpbmNlIGhlbGxvIGFkamFj ZW5jaWVzIGFyZSBhc3NvY2lhdGVkIHdpdGggYSBsaW5rLCBzdGlsbCBmYXRlDQo8YnI+DQomZ3Q7 ICZndDsgc2hhcmluZyB3b3VsZCBjb250aW51ZSBvdmVyIHRoZSBzaW5nbGUgbGRwL3RjcCBzZXNz aW9uIGZvciBJUFY0DQphbmQgSVBWNi48YnI+DQomZ3Q7ICZndDsgSGF2aW5nIElQVjQgYW5kIElQ VjYgc3BlY2lmaWMgaGVsbG8gYWRqYWNlbmNpZXMgb3ZlciBhIGxpbmsgd291bGQNCjxicj4NCiZn dDsgJmd0OyBvbmx5IGRlY2lkZSB3aGV0aGVyIHN1Y2ggYSBsaW5rIGlzIHRvIGJlIHByb2dyYW1t ZWQgZm9yIElQVjQNCm9yIElQVjY8YnI+DQomZ3Q7ICZndDsgZWdyZXNzIHRyYWZmaWMgYnV0IEkg c2VlIGl0IGFzIG92ZXJraWxsIGFuZCB1bm5lY2Vzc2FyeSBzY2FsYWJpbGl0eQ0KaW1wYWN0cy48 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsgUHJh bmphbDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1wbHMgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyBtcGxzQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0 PiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFN5ZWQgS2FtcmFuIFJhemE8YnI+DQomZ3Q7 IFRlY2huaWNhbCBMZWFkZXIsIFNQUlNHIElPUy1YUiBSb3V0aW5nIChNUExTKTxicj4NCiZndDsg Q2lzY28gU3lzdGVtcywgSW5jLiwgPGJyPg0KJmd0OyBLYW5hdGEsIE9OLCBLMksgM0U4LCBDYW5h ZGEgPGJyPg0KJmd0OyBQaDogKzEgKDYxMykgMjU0LTQ1MjA8YnI+DQomZ3Q7IGh0dHA6Ly93d3cu Y2lzY28uY29tIDxicj4NCiZndDsgPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+PHByZT4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUm bmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNw O2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZu YnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3Nl bmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtu YW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWlu dGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0 ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZu YnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5i c3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5i c3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7 aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7 d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3Um bmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNw O2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZu YnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4 cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9z ZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJz cDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2 aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFt Jm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000D56D24825799E_=-- From lizhong.jin@zte.com.cn Tue Feb 7 18:49: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 5873E11E80A6 for ; Tue, 7 Feb 2012 18:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.56 X-Spam-Level: X-Spam-Status: No, score=-100.56 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hdCvN6NPnZu0 for ; Tue, 7 Feb 2012 18:49:18 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7C711E8096 for ; Tue, 7 Feb 2012 18:49:15 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690806486374; Wed, 8 Feb 2012 10:22:43 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.8552164185; Wed, 8 Feb 2012 10:49:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q182n16m099144; Wed, 8 Feb 2012 10:49:01 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Kamran Raza MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Wed, 8 Feb 2012 10:48:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 10:49:01, Serialize complete at 2012-02-08 10:49:01 Content-Type: multipart/alternative; boundary="=_alternative 000F79804825799E_=" X-MAIL: mse01.zte.com.cn q182n16m099144 Cc: "mpls@ietf.org" , "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 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 02:49:19 -0000 This is a multipart message in MIME format. --=_alternative 000F79804825799E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkNCj4gPj4gUmU6IE11bHRpcGxlIHNlc3Npb24gYmV0d2VlbiBzYW1lIExTUg0KPiBBRkFJUiwg dGhlIGlkZWEgb2YgdXNpbmcgbW9yZSB0aGFuIG9uZSBMRFAgc2Vzc2lvbiAod2hpbGUgdXNpbmcg DQo+IHBsYXRmb3JtLXdpZGUgbGFiZWwgc3BhY2UpIGJldHdlZW4gdHdvIExTUnMgaGFzIGJlZW4g DQo+IHByb3Bvc2VkL2Rpc2N1c3NlZCBpbiBJRVRGIFdHcyBbIE1QTFMvUFdFM10gYmVmb3JlIGFz IHdlbGwgKGUuZy4gDQo+IElDQ1ApLCBidXQgd2FzIHJlamVjdGVkLg0KW0xpemhvbmddIEkgdGhp bmsgdGhlIHJlcXVpcmVtZW50IG9mIHR3byBzZXNzaW9ucyBmb3IgSVB2NCBhbmQgSVB2NiBpcyAN CmRpZmZlcmVudCB3aXRoIHRoZSBjYXNlIG9mIElDQ1AuIFRoaXMgaXMgcmVsYXRlZCB3aXRoIGN1 cnJlbnQgZHVhbC1zdGFjayANCklQdjQvdjYgZGVwbG95bWVudCBhbmQgb3BlcmF0aW9ucyBhcyBT aGFuZSBtZW50aW9uZWQuDQoNClRoYW5rcw0KTGl6aG9uZw0KDQo+IA0KPiBJZiBJoa92ZSB0byBj aG9zZSBiZXR3ZWVuIENhcGFiaWxpdGllcyBiYXNlZCBzb2x1dGlvbiBhbmQgU2VwYXJhdGUgDQo+ IExEUCBzZXNzaW9uIHRvIHN1cHBvcnQgSVB2NC9JUHY2IExEUCwgSSB3aWxsIGdvIHdpdGggTERQ IA0KPiBDYXBhYmlsaXRpZXMgYmFzZWQgc29sdXRpb24uDQo+IA0KPiBNeSAyIGNlbnRzLg0KPiAN Cj4gT24gMTItMDItMDcgMTA6MDMgQU0sICJBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKSIg PG11c3RhcGhhLg0KPiBhaXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KDQo+IEth bXJhbiwNCj4gaW4gTERQLCB0aGUgYWJpbGl0eSB0byBhZHZlcnRpc2UgYSBGRUMgdHlwZSBiZXR3 ZWVuIHBlZXJzIGlzIA0KPiBpbmRlcGVuZGVudCBvZiB0aGUgYWRqYWNlbmN5IGVzdGFibGlzaGVk LiBJIGFtIG5vdCBzdXJlIHdoeSB0aGlzIHdhcw0KPiBub3QgYW4gaXNzdWUgZm9yIG90aGVyIEZF QyB0eXBlcyAodW5pY2FzdCBJUHY0IEZFQywgUFcgRkVDLCBtTERQIA0KPiBwMm1wIEZFQykgYW5k IGl0IGlzIG5vdyBmb3IgdW5pY2FzdCBJUHY2IEZFQyBwcmVmaXhlcy4gVGhlIHVzZXIgDQo+IGNv bnRyb2xzIHdoaWNoIHByZWZpeCB0eXBlIHRvIGFkdmVydGl6ZS9hY2NlcHQgdG8vZnJvbSBhIHBl ZXIgdmlhIA0KPiBpbXBvcnQvZXhwb3J0IHBvbGljaWVzIGFuZCBMRFAgbm9kZSBjYXBhYmlsaXR5 IGFkdmVydGlzZW1lbnQuDQo+IA0KPiBZb3UgcG9pbnQgMiBiZWxvdyBpcyBhYm91dCBGRUMgcmVz b2x1dGlvbiBhbmQgbm90IEZFQyBhZHZlcnRpc2VtZW50Lg0KPiBXaGVuIHlvdSByZXNvbHZlIGEg RkVDLCB5b3UgbmVlZCB0byBjaGVjayB3aGljaCBMU1ItaWQgb3ducyB0aGUgDQo+IG5leHQtaG9w IGluIHRoZSByb3V0aW5nIHRhYmxlIGZvciB0aGUgSVB2NiBwcmVmaXggYW5kIHRoaXMgaXMgDQo+ IHByb3ZpZGVkIGJ5IHRoZSBsaXN0IG9mIGludGVyZmFjZSBhZGRyZXNzZXMgaW4gdGhlIEFkZHJl c3MgTGlzdCBUTFYuDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGEgbGFiZWwgZm9yIHRoZSBGRUMg ZnJvbSB0aGUgTFNSLWlkIHdoaWNoIG93bnMgDQo+IHRoZSBJUHY2IG5leHQtaG9wLCB5b3UgY2Fu IHJlc29sdmUgdGhlIEZFQyB0byB0aGF0IGludGVyZmFjZSBldmVuIGlmDQo+IHRoZSBIZWxsbyBh ZGphY2VuY3kgb3ZlciB0aGF0IGludGVyZmFjZSBpcyBJUHY0IG9ubHkuIA0KPiANCj4gV2UgbmVl ZCB0byBrZWVwIHRoYXQgc2VwYXJhdGlvbiBiZXR3ZWVuIEZFQyBhZHZlcnRpc2VtZW50IGFuZCAN Cj4gYWRqYWNlbmN5IHR5cGUgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBSRkMgNTAz Ni4gV2hhdCB3ZSANCj4gbmVlZCBpbiBteSB2aWV3IGlzIHRvIHJlbGF4IFJGQyA1MDM2IHRvIGFs bG93IHRoZSBzZXR1cCBvZiBtdWx0aXBsZSANCj4gTERQIGFkamFjZW5jaWVzL3Nlc3Npb25zIGJl dHdlZW4gdHdvIExTUnMgd2hpY2ggdXNlIHR3byBkaWZmZXJlbnQgDQo+IExTUi1pZCBidXQgdGhl IHNhbWUgZ2xvYmFsIGxhYmVsLXNwYWNlLWlkLiBUaGlzIGNhbiBiZSBkb25lIHdpdGggDQo+IHNv bWUgcnVsZXMgdG8gYXZvaWQgbG9vcHMuIFVzZXJzIHdpbGwgdGhlbiBiZSBmcmVlIHRvIGRlZGlj YXRlIGFuIA0KPiBMRFAgc2Vzc2lvbiBmb3IgSVB2NiBwcmVmaXhlcyBhbmQgYW5vdGhlciBmb3Ig SVB2NCBwcmVmaXhlcyBtdWNoIA0KPiBsaWtlIHRoZSBCR1AgbW9kZWwgYWxsb3dzIGZvci4NCj4g DQo+IFJlZ2FyZHMsDQo+IE11c3RhcGhhLg0KPiANCj4gRnJvbTogS2FtcmFuIFJhemEgW21haWx0 bzpza3JhemFAY2lzY28uY29tXSANCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAwNiwgMjAxMiAx MTo1MCBQTQ0KPiBUbzogTGl6aG9uZyBKaW47IER1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpOyB2 aXNod2FzLmlldGZAZ21haWwuY29tOw0KPiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKQ0K PiBDYzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRy YWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0wNg0KPiANCj4gSGkgTGl6aG9uZywNCj4gDQo+IFVzaW5n IHNpbmdsZSBhZGogWyBhbmQganVzdCBjaGVja2luZyBsb2NhbCBpbnRlcmZhY2UgZW5hYmxpbmcg Zm9yIA0KPiBnaXZlbiBBRiArIGNhcGFiaWxpdGllcyBdIHdpbGwgbm90IHN1ZmZpY2Uvd29yayBi ZWNhdXNlOg0KPiANCj4gIDEuIExEUCBjYXBhYmlsaXRpZXMgYXJlIGFkdmVydGlzZWQgb24gcGVl ci9zZXNzaW9uIGxldmVsIGFuZCBkbyBub3QNCj4gY29ycmVzcG9uZCB0byBhZGogY2FwYWJpbGl0 aWVzLg0KPiAgMi4gQW4gTFNSIG11c3Qgbm90IGJlIGZvcndhcmRpbmcgTVBMUyBvbiBhbiBpbnRl cmZhY2UgdW5sZXNzL3VudGlsIA0KPiBpdCBoYXMgZ290IGFuIE1QTFMgYWRqIG9uIGl0IKhDIGV4 dGVuZGluZyB0aGUgc2FtZSB0byBhZGRyZXNzIA0KPiBmYW1pbGllcywgYW4gTFNSIG11c3Qgbm90 IGZvcndhcmQgTVBMUyB2NiBvbiBhbiBpbnRlcmZhY2UgdW5sZXNzIGl0IA0KPiBoYXMgZ290IE1Q TFMgdjYgYWRqIG9uIGl0LiBbIFNpbmdsZSBhZGogd2lsbCBub3QgY29udmV5IHVzIHJlbW90ZSAN Cj4gbm9kZaGvcyBpbnRlcmZhY2UgY2FwYWJpbGl0eSBmb3IgZ2l2ZW4gQUYsIGFuZCBpdCB3aWxs IGJlIGluY29ycmVjdCANCj4gdG8gZm9yd2FyZCA2IE1QTFMgbGFiZWxsZWQgdHJhZmZpYyBvbiBp dCB1bmxlc3Mgd2Uga25vdyB0aGF0IHJlbW90ZSANCj4gaW50ZiBpcyB2NiBNUExTIGVuYWJsZWQg XQ0KPiANCj4gIE15IDIgY2VudHMuDQo+IC0tIEthbXJhbg0KPiANCj4gT24gMTItMDItMDYgMTA6 MjIgUE0sICJMaXpob25nIEppbiIgPGxpemhvbmcuamluQHp0ZS5jb20uY24+IHdyb3RlOg0KDQo+ IA0KPiBIaSwgDQo+IEkgd29uZGVyIGlmIGl0IGlzIGZlYXNpYmxlIHRvIHVzZSBMRFAgIGNhcGFi aWxpdHkgdG8gYWR2ZXJ0aXNlIElQdjYgDQo+IEZFQyB3aXRob3V0IElQdjYgYWRqYWNlbmN5LCBh bmQgb25seSB1c2Ugb25lICBhZGphY2VuY3kgZm9yIExEUCANCj4gc2Vzc2lvbiBpbiBkdWFsLXN0 YWNrIG5ldHdvcmsuIExEUCBjYXBhYmlsaXR5IGlzIHBlciBub2RlIA0KPiBjYXBhYmlsaXR5LCBu b3QgcGVyIGludGVyZmFjZSBjYXBhYmlsaXR5LiBCdXQgZm9yIExEUCB0byBjaG9vc2UgdGhlIA0K PiBjb3JyZWN0ICBkb3duc3RyZWFtIHNlc3Npb24gYW5kIG91dHB1dCBpbnRlcmZhY2UgZm9yIGVh Y2ggRkVDLCBpdCANCj4gc2hvdWxkIGFsc28gY2hlY2sgaWYgIHRoZSBvdXRwdXQgaW50ZXJmYWNl IGlzIExEUCBlbmFibGVkIG9yIG5vdC4gDQo+IFRoZSBsaW5rIGFkamFjZW5jeSBjb3VsZCBiZSB1 c2VkICB0byBhc3Npc3Qgc3VjaCBraW5kIG9mIGNoZWNraW5nLiANCj4gDQo+IFtLYW1yYW5dOg0K PiANCj4gSG93ZXZlciwgSU1PLCBpdCBpcyAgdmFsdWFibGUgdG8gYWxsb3cgdHdvIGluZGVwZW5k ZW50IExEUCBzZXNzaW9ucyANCj4gZm9yIElQdjQgYW5kIElQdjYgYXMgYW4gb3B0aW9uLiAgUmVn YXJkaW5nIHRoZSBmb3JtYXQgZGVmaW5pdGlvbiBpbiANCj4gUkZDNTAzNiwgd2UgbWF5IG5lZWQg bmV3IExEUCB2ZXJzaW9uIG51bWJlciAgdG8gaWRlbnRpZnkgSVB2NiBMU1ItDQo+IElELiBPciB3 ZSB1c2UgZGlmZmVyZW50IDMyYml0IExTUi1JRCBmb3IgSVB2NiB3aXRoIElQdjQsICBidXQgSSAN Cj4gcHJlZmVyIG5ldyBmb3JtYXQgb2YgTFNSLUlELiANCj4gDQo+IFJlZ2FyZHMgDQo+IExpemhv bmcgDQo+IA0KPiANCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gDQo+ID4gTWVzc2FnZTogMQ0KPiA+ IERhdGU6IFR1ZSwgNyBGZWIgMjAxMiAwNToyODoyMSArMDUzMA0KPiA+IEZyb206ICAiRHV0dGEs IFByYW5qYWwgSyAoUHJhbmphbCkiIDxwcmFuamFsLmR1dHRhQGFsY2F0ZWwtbHVjZW50LmNvbT4N Cj4gPiAgVG86IFZpc2h3YXMgTWFucmFsIDx2aXNod2FzLmlldGZAZ21haWwuY29tPg0KPiA+IENj OiAgIkFpc3Nhb3VpLCBNdXN0YXBoYSBcKE11c3RhcGhhXCkiDQo+ID4gICAgPG11c3RhcGhhLmFp c3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbT4sICAgIm1wbHNAaWV0Zi5vcmciDQo+ID4gICAgIDxt cGxzQGlldGYub3JnPg0KPiA+ICBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtbXBscy1sZHAtaXB2Ni0wNg0KPiA+ICBNZXNzYWdlLUlEOg0KPiA+ICAgIDxDNTg0MDQ2 NDY2RUQyMjRDQTkyQzFCQzMzMTNCOTYzRTA5RUZFOEQ2NjdASU5CQU5TWENITUJTQTMuaW4uDQo+ ID4gIGFsY2F0ZWwtbHVjZW50LmNvbT4NCj4gPiANCj4gPiBDb250ZW50LVR5cGU6ICB0ZXh0L3Bs YWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCj4gPiANCj4gPiBJIHdvdWxkIHJhdGhlciBmb3IgY29t cGxldGUgIHNlcGFyYXRpb24gd2l0aCBtdWx0aXBsZSBsc3ItaWQgYmVjYXVzZSANCj4gPiBoYXZp bmcgc2VwYXJhdGUgbGluayAgYWRqYWNlbmNpZXMgZG9lcyBub3QgcmVhbGx5IHNvbHZlZCBhbnkg cHJvYmxlbS4NCj4gPiBTaW5jZSBoZWxsbyAgYWRqYWNlbmNpZXMgYXJlIGFzc29jaWF0ZWQgd2l0 aCBhIGxpbmssIHN0aWxsIGZhdGUgDQo+ID4gc2hhcmluZyB3b3VsZCAgY29udGludWUgb3ZlciB0 aGUgc2luZ2xlIGxkcC90Y3Agc2Vzc2lvbiBmb3IgSVBWNCBhbmQgDQpJUFY2Lg0KPiA+IEhhdmlu ZyAgSVBWNCBhbmQgSVBWNiBzcGVjaWZpYyBoZWxsbyBhZGphY2VuY2llcyBvdmVyIGEgbGluayB3 b3VsZCANCj4gPiBvbmx5ICBkZWNpZGUgd2hldGhlciBzdWNoIGEgbGluayBpcyB0byBiZSBwcm9n cmFtbWVkIGZvciBJUFY0IG9yIElQVjYNCj4gPiBlZ3Jlc3MgIHRyYWZmaWMgYnV0IEkgc2VlIGl0 IGFzIG92ZXJraWxsIGFuZCB1bm5lY2Vzc2FyeSANCj4gc2NhbGFiaWxpdHkgaW1wYWN0cy4NCj4g PiANCj4gPiBUaGFua3MsDQo+ID4gUHJhbmphbA0KPiA+IA0KPiANCj4gLS0tLS0NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyAgbWFpbGlu ZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzDQo+IA0KPiAtLSANCj4gU3llZCBLYW1yYW4gUmF6YQ0KPiBUZWNobmljYWwg TGVhZGVyLCBTUFJTRyBJT1MtWFIgUm91dGluZyAoTVBMUykNCj4gQ2lzY28gU3lzdGVtcywgSW5j LiwgDQo+IEthbmF0YSwgT04sIEsySyAzRTgsIENhbmFkYSANCj4gUGg6ICsxICg2MTMpIDI1NC00 NTIwDQo+IGh0dHA6Ly93d3cuY2lzY28uY29tIA0KPiANCj4gDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMg bWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92 ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJz Lg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000F79804825799E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBSZTogTXVsdGlwbGUgc2Vzc2lvbiBiZXR3ZWVuIHNhbWUgTFNSPGJyPg0KJmd0OyBBRkFJUiwg dGhlIGlkZWEgb2YgdXNpbmcgbW9yZSB0aGFuIG9uZSBMRFAgc2Vzc2lvbiAod2hpbGUgdXNpbmcg PGJyPg0KJmd0OyBwbGF0Zm9ybS13aWRlIGxhYmVsIHNwYWNlKSBiZXR3ZWVuIHR3byBMU1JzIGhh cyBiZWVuIDxicj4NCiZndDsgcHJvcG9zZWQvZGlzY3Vzc2VkIGluIElFVEYgV0dzIFsgTVBMUy9Q V0UzXSBiZWZvcmUgYXMgd2VsbCAoZS5nLiA8YnI+DQomZ3Q7IElDQ1ApLCBidXQgd2FzIHJlamVj dGVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+W0xpemhvbmdd IEkgdGhpbmsgdGhlIHJlcXVpcmVtZW50IG9mDQp0d28gc2Vzc2lvbnMgZm9yIElQdjQgYW5kIElQ djYgaXMgZGlmZmVyZW50IHdpdGggdGhlIGNhc2Ugb2YgSUNDUC4gVGhpcw0KaXMgcmVsYXRlZCB3 aXRoIGN1cnJlbnQgZHVhbC1zdGFjayBJUHY0L3Y2IGRlcGxveW1lbnQgYW5kIG9wZXJhdGlvbnMg YXMNClNoYW5lIG1lbnRpb25lZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+TGl6aG9uZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIEmhr3ZlIHRvIGNob3NlIGJldHdlZW4gQ2FwYWJpbGl0 aWVzIGJhc2VkIHNvbHV0aW9uIGFuZCBTZXBhcmF0ZQ0KPGJyPg0KJmd0OyBMRFAgc2Vzc2lvbiB0 byBzdXBwb3J0IElQdjQvSVB2NiBMRFAsIEkgd2lsbCBnbyB3aXRoIExEUCA8YnI+DQomZ3Q7IENh cGFiaWxpdGllcyBiYXNlZCBzb2x1dGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsgPGJyPg0KJmd0OyBNeSAyIGNlbnRzLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBPbiAxMi0wMi0wNyAxMDowMyBBTSwgJnF1b3Q7QWlzc2FvdWksIE11c3RhcGhhIChNdXN0 YXBoYSkmcXVvdDsgJmx0O211c3RhcGhhLjxicj4NCiZndDsgYWlzc2FvdWlAYWxjYXRlbC1sdWNl bnQuY29tJmd0OyB3cm90ZTo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsgS2FtcmFuLDxicj4NCiZndDsgaW4gTERQLCB0aGUgYWJpbGl0eSB0byBh ZHZlcnRpc2UgYSBGRUMgdHlwZSBiZXR3ZWVuIHBlZXJzIGlzIDxicj4NCiZndDsgaW5kZXBlbmRl bnQgb2YgdGhlIGFkamFjZW5jeSBlc3RhYmxpc2hlZC4gSSBhbSBub3Qgc3VyZSB3aHkgdGhpcyB3 YXM8YnI+DQomZ3Q7IG5vdCBhbiBpc3N1ZSBmb3Igb3RoZXIgRkVDIHR5cGVzICh1bmljYXN0IElQ djQgRkVDLCBQVyBGRUMsIG1MRFAgPGJyPg0KJmd0OyBwMm1wIEZFQykgYW5kIGl0IGlzIG5vdyBm b3IgdW5pY2FzdCBJUHY2IEZFQyBwcmVmaXhlcy4gVGhlIHVzZXIgPGJyPg0KJmd0OyBjb250cm9s cyB3aGljaCBwcmVmaXggdHlwZSB0byBhZHZlcnRpemUvYWNjZXB0IHRvL2Zyb20gYSBwZWVyIHZp YQ0KPGJyPg0KJmd0OyBpbXBvcnQvZXhwb3J0IHBvbGljaWVzIGFuZCBMRFAgbm9kZSBjYXBhYmls aXR5IGFkdmVydGlzZW1lbnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFlvdSBwb2ludCAyIGJlbG93 IGlzIGFib3V0IEZFQyByZXNvbHV0aW9uIGFuZCBub3QgRkVDIGFkdmVydGlzZW1lbnQuPGJyPg0K Jmd0OyBXaGVuIHlvdSByZXNvbHZlIGEgRkVDLCB5b3UgbmVlZCB0byBjaGVjayB3aGljaCBMU1It aWQgb3ducyB0aGUgPGJyPg0KJmd0OyBuZXh0LWhvcCBpbiB0aGUgcm91dGluZyB0YWJsZSBmb3Ig dGhlIElQdjYgcHJlZml4IGFuZCB0aGlzIGlzIDxicj4NCiZndDsgcHJvdmlkZWQgYnkgdGhlIGxp c3Qgb2YgaW50ZXJmYWNlIGFkZHJlc3NlcyBpbiB0aGUgQWRkcmVzcyBMaXN0IFRMVi48YnI+DQom Z3Q7IElmIHlvdSBoYXZlIHJlY2VpdmVkIGEgbGFiZWwgZm9yIHRoZSBGRUMgZnJvbSB0aGUgTFNS LWlkIHdoaWNoIG93bnMNCjxicj4NCiZndDsgdGhlIElQdjYgbmV4dC1ob3AsIHlvdSBjYW4gcmVz b2x2ZSB0aGUgRkVDIHRvIHRoYXQgaW50ZXJmYWNlIGV2ZW4NCmlmPGJyPg0KJmd0OyB0aGUgSGVs bG8gYWRqYWNlbmN5IG92ZXIgdGhhdCBpbnRlcmZhY2UgaXMgSVB2NCBvbmx5LiA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgV2UgbmVlZCB0byBrZWVwIHRoYXQgc2VwYXJhdGlvbiBiZXR3ZWVuIEZFQyBh ZHZlcnRpc2VtZW50IGFuZCA8YnI+DQomZ3Q7IGFkamFjZW5jeSB0eXBlIGZvciBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IHdpdGggUkZDIDUwMzYuIFdoYXQgd2UgPGJyPg0KJmd0OyBuZWVkIGluIG15 IHZpZXcgaXMgdG8gcmVsYXggUkZDIDUwMzYgdG8gYWxsb3cgdGhlIHNldHVwIG9mIG11bHRpcGxl DQo8YnI+DQomZ3Q7IExEUCBhZGphY2VuY2llcy9zZXNzaW9ucyBiZXR3ZWVuIHR3byBMU1JzIHdo aWNoIHVzZSB0d28gZGlmZmVyZW50DQo8YnI+DQomZ3Q7IExTUi1pZCBidXQgdGhlIHNhbWUgZ2xv YmFsIGxhYmVsLXNwYWNlLWlkLiBUaGlzIGNhbiBiZSBkb25lIHdpdGggPGJyPg0KJmd0OyBzb21l IHJ1bGVzIHRvIGF2b2lkIGxvb3BzLiBVc2VycyB3aWxsIHRoZW4gYmUgZnJlZSB0byBkZWRpY2F0 ZSBhbg0KPGJyPg0KJmd0OyBMRFAgc2Vzc2lvbiBmb3IgSVB2NiBwcmVmaXhlcyBhbmQgYW5vdGhl ciBmb3IgSVB2NCBwcmVmaXhlcyBtdWNoIDxicj4NCiZndDsgbGlrZSB0aGUgQkdQIG1vZGVsIGFs bG93cyBmb3IuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBNdXN0YXBo YS48YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJvbTogS2FtcmFuIFJhemEgW21haWx0bzpza3JhemFA Y2lzY28uY29tXSA8YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDYsIDIwMTIgMTE6 NTAgUE08YnI+DQomZ3Q7IFRvOiBMaXpob25nIEppbjsgRHV0dGEsIFByYW5qYWwgSyAoUHJhbmph bCk7IHZpc2h3YXMuaWV0ZkBnbWFpbC5jb207PGJyPg0KJmd0OyBBaXNzYW91aSwgTXVzdGFwaGEg KE11c3RhcGhhKTxicj4NCiZndDsgQ2M6IG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6 IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEhpIExpemhvbmcsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFVzaW5nIHNp bmdsZSBhZGogWyBhbmQganVzdCBjaGVja2luZyBsb2NhbCBpbnRlcmZhY2UgZW5hYmxpbmcgZm9y DQo8YnI+DQomZ3Q7IGdpdmVuIEFGICsgY2FwYWJpbGl0aWVzIF0gd2lsbCBub3Qgc3VmZmljZS93 b3JrIGJlY2F1c2U6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOzEuIExEUCBjYXBhYmlsaXRp ZXMgYXJlIGFkdmVydGlzZWQgb24gcGVlci9zZXNzaW9uIGxldmVsIGFuZA0KZG8gbm90PGJyPg0K Jmd0OyBjb3JyZXNwb25kIHRvIGFkaiBjYXBhYmlsaXRpZXMuPGJyPg0KJmd0OyAmbmJzcDsyLiBB biBMU1IgbXVzdCBub3QgYmUgZm9yd2FyZGluZyBNUExTIG9uIGFuIGludGVyZmFjZSB1bmxlc3Mv dW50aWwNCjxicj4NCiZndDsgaXQgaGFzIGdvdCBhbiBNUExTIGFkaiBvbiBpdCCoQyBleHRlbmRp bmcgdGhlIHNhbWUgdG8gYWRkcmVzcyA8YnI+DQomZ3Q7IGZhbWlsaWVzLCBhbiBMU1IgbXVzdCBu b3QgZm9yd2FyZCBNUExTIHY2IG9uIGFuIGludGVyZmFjZSB1bmxlc3MgaXQNCjxicj4NCiZndDsg aGFzIGdvdCBNUExTIHY2IGFkaiBvbiBpdC4gWyBTaW5nbGUgYWRqIHdpbGwgbm90IGNvbnZleSB1 cyByZW1vdGUNCjxicj4NCiZndDsgbm9kZaGvcyBpbnRlcmZhY2UgY2FwYWJpbGl0eSBmb3IgZ2l2 ZW4gQUYsIGFuZCBpdCB3aWxsIGJlIGluY29ycmVjdA0KPGJyPg0KJmd0OyB0byBmb3J3YXJkIDYg TVBMUyBsYWJlbGxlZCB0cmFmZmljIG9uIGl0IHVubGVzcyB3ZSBrbm93IHRoYXQgcmVtb3RlDQo8 YnI+DQomZ3Q7IGludGYgaXMgdjYgTVBMUyBlbmFibGVkIF08YnI+DQomZ3Q7IDxicj4NCiZndDsg Jm5ic3A7TXkgMiBjZW50cy48YnI+DQomZ3Q7IC0tIEthbXJhbjxicj4NCiZndDsgPGJyPg0KJmd0 OyBPbiAxMi0wMi0wNiAxMDoyMiBQTSwgJnF1b3Q7TGl6aG9uZyBKaW4mcXVvdDsgJmx0O2xpemhv bmcuamluQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgPGJyPg0KJmd0OyBIaSwgPGJyPg0KJmd0OyBJIHdv bmRlciBpZiBpdCBpcyBmZWFzaWJsZSB0byB1c2UgTERQICZuYnNwO2NhcGFiaWxpdHkgdG8gYWR2 ZXJ0aXNlDQpJUHY2IDxicj4NCiZndDsgRkVDIHdpdGhvdXQgSVB2NiBhZGphY2VuY3ksIGFuZCBv bmx5IHVzZSBvbmUgJm5ic3A7YWRqYWNlbmN5IGZvciBMRFANCjxicj4NCiZndDsgc2Vzc2lvbiBp biBkdWFsLXN0YWNrIG5ldHdvcmsuIExEUCBjYXBhYmlsaXR5IGlzIHBlciBub2RlICZuYnNwOzxi cj4NCiZndDsgY2FwYWJpbGl0eSwgbm90IHBlciBpbnRlcmZhY2UgY2FwYWJpbGl0eS4gQnV0IGZv ciBMRFAgdG8gY2hvb3NlIHRoZQ0KPGJyPg0KJmd0OyBjb3JyZWN0ICZuYnNwO2Rvd25zdHJlYW0g c2Vzc2lvbiBhbmQgb3V0cHV0IGludGVyZmFjZSBmb3IgZWFjaCBGRUMsDQppdCA8YnI+DQomZ3Q7 IHNob3VsZCBhbHNvIGNoZWNrIGlmICZuYnNwO3RoZSBvdXRwdXQgaW50ZXJmYWNlIGlzIExEUCBl bmFibGVkIG9yDQpub3QuIDxicj4NCiZndDsgVGhlIGxpbmsgYWRqYWNlbmN5IGNvdWxkIGJlIHVz ZWQgJm5ic3A7dG8gYXNzaXN0IHN1Y2gga2luZCBvZiBjaGVja2luZy4NCjxicj4NCiZndDsgPGJy Pg0KJmd0OyBbS2FtcmFuXTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSG93ZXZlciwgSU1PLCBpdCBp cyAmbmJzcDt2YWx1YWJsZSB0byBhbGxvdyB0d28gaW5kZXBlbmRlbnQgTERQIHNlc3Npb25zDQo8 YnI+DQomZ3Q7IGZvciBJUHY0IGFuZCBJUHY2IGFzIGFuIG9wdGlvbi4gJm5ic3A7UmVnYXJkaW5n IHRoZSBmb3JtYXQgZGVmaW5pdGlvbg0KaW4gPGJyPg0KJmd0OyBSRkM1MDM2LCB3ZSBtYXkgbmVl ZCBuZXcgTERQIHZlcnNpb24gbnVtYmVyICZuYnNwO3RvIGlkZW50aWZ5IElQdjYNCkxTUi08YnI+ DQomZ3Q7IElELiBPciB3ZSB1c2UgZGlmZmVyZW50IDMyYml0IExTUi1JRCBmb3IgSVB2NiB3aXRo IElQdjQsICZuYnNwO2J1dA0KSSA8YnI+DQomZ3Q7IHByZWZlciBuZXcgZm9ybWF0IG9mIExTUi1J RC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMgPGJyPg0KJmd0OyBMaXpob25nICZuYnNw Ozxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgTWVzc2FnZTogMTxicj4NCiZn dDsgJmd0OyBEYXRlOiBUdWUsIDcgRmViIDIwMTIgMDU6Mjg6MjEgKzA1MzA8YnI+DQomZ3Q7ICZn dDsgRnJvbTogJm5ic3A7JnF1b3Q7RHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCkmcXVvdDsgJmx0 O3ByYW5qYWwuZHV0dGFAYWxjYXRlbC1sdWNlbnQuY29tJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJz cDtUbzogVmlzaHdhcyBNYW5yYWwgJmx0O3Zpc2h3YXMuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IENjOiAmbmJzcDsmcXVvdDtBaXNzYW91aSwgTXVzdGFwaGEgXChNdXN0YXBoYVwp JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsmbHQ7bXVzdGFwaGEuYWlzc2FvdWlA YWxjYXRlbC1sdWNlbnQuY29tJmd0OywgJm5ic3A7DQomcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwO1N1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0 Zi1tcGxzLWxkcC1pcHY2LTA2PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO01lc3NhZ2UtSUQ6PGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsmbHQ7QzU4NDA0NjQ2NkVEMjI0Q0E5MkMxQkMzMzEzQjk2 M0UwOUVGRThENjY3QElOQkFOU1hDSE1CU0EzLmluLjxicj4NCiZndDsgJmd0OyAmbmJzcDthbGNh dGVsLWx1Y2VudC5jb20mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7 ICZndDsgQ29udGVudC1UeXBlOiAmbmJzcDt0ZXh0L3BsYWluOyBjaGFyc2V0PSZxdW90O3VzLWFz Y2lpJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIHdvdWxkIHJhdGhlciBm b3IgY29tcGxldGUgJm5ic3A7c2VwYXJhdGlvbiB3aXRoIG11bHRpcGxlIGxzci1pZA0KYmVjYXVz ZSA8YnI+DQomZ3Q7ICZndDsgaGF2aW5nIHNlcGFyYXRlIGxpbmsgJm5ic3A7YWRqYWNlbmNpZXMg ZG9lcyBub3QgcmVhbGx5IHNvbHZlZA0KYW55IHByb2JsZW0uPGJyPg0KJmd0OyAmZ3Q7IFNpbmNl IGhlbGxvICZuYnNwO2FkamFjZW5jaWVzIGFyZSBhc3NvY2lhdGVkIHdpdGggYSBsaW5rLCBzdGls bA0KZmF0ZSA8YnI+DQomZ3Q7ICZndDsgc2hhcmluZyB3b3VsZCAmbmJzcDtjb250aW51ZSBvdmVy IHRoZSBzaW5nbGUgbGRwL3RjcCBzZXNzaW9uDQpmb3IgSVBWNCBhbmQgSVBWNi48YnI+DQomZ3Q7 ICZndDsgSGF2aW5nICZuYnNwO0lQVjQgYW5kIElQVjYgc3BlY2lmaWMgaGVsbG8gYWRqYWNlbmNp ZXMgb3ZlciBhDQpsaW5rIHdvdWxkIDxicj4NCiZndDsgJmd0OyBvbmx5ICZuYnNwO2RlY2lkZSB3 aGV0aGVyIHN1Y2ggYSBsaW5rIGlzIHRvIGJlIHByb2dyYW1tZWQgZm9yDQpJUFY0IG9yIElQVjY8 YnI+DQomZ3Q7ICZndDsgZWdyZXNzICZuYnNwO3RyYWZmaWMgYnV0IEkgc2VlIGl0IGFzIG92ZXJr aWxsIGFuZCB1bm5lY2Vzc2FyeQ0KPGJyPg0KJmd0OyBzY2FsYWJpbGl0eSBpbXBhY3RzLjxicj4N CiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgVGhhbmtzLDxicj4NCiZndDsgJmd0OyBQ cmFuamFsPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLTxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IG1wbHMgJm5ic3A7bWFpbGluZyBsaXN0PGJyPg0KJmd0OyBtcGxzQGlldGYub3Jn PGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgPGJyPg0KJmd0OyAt LSA8YnI+DQomZ3Q7IFN5ZWQgS2FtcmFuIFJhemE8YnI+DQomZ3Q7IFRlY2huaWNhbCBMZWFkZXIs IFNQUlNHIElPUy1YUiBSb3V0aW5nIChNUExTKTxicj4NCiZndDsgQ2lzY28gU3lzdGVtcywgSW5j LiwgPGJyPg0KJmd0OyBLYW5hdGEsIE9OLCBLMksgM0U4LCBDYW5hZGEgPGJyPg0KJmd0OyBQaDog KzEgKDYxMykgMjU0LTQ1MjA8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuY2lzY28uY29tIDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1h dGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9u Jm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7 c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7 b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fi b3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3Nl Y3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZu YnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJz cDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNw O2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJz cDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3Ro ZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5i c3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7 cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5i c3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7 YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVt Lg0KPC9wcmU+ --=_alternative 000F79804825799E_=-- From loa@pi.nu Wed Feb 8 05:26: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 E42FD21F86B4 for ; Wed, 8 Feb 2012 05:26:43 -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=[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 llsATR3+c7zF for ; Wed, 8 Feb 2012 05:26:43 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 26F3021F8633 for ; Wed, 8 Feb 2012 05:26:41 -0800 (PST) Received: from [192.168.4.14] (a50.fluent.fr [195.68.67.50]) (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 BD6D2514002; Wed, 8 Feb 2012 14:26:39 +0100 (CET) Message-ID: <4F327811.1000700@pi.nu> Date: Wed, 08 Feb 2012 14:26:41 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] 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: Wed, 08 Feb 2012 13:26:44 -0000 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 Alexander.Vainshtein@ecitele.com Wed Feb 8 05:37: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 3917F21F84F7 for ; Wed, 8 Feb 2012 05:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 ziCgD6-a2IS3 for ; Wed, 8 Feb 2012 05:37:38 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 780DC21F8503 for ; Wed, 8 Feb 2012 05:37:38 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1328708252!8344663!2 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 2463 invoked from network); 8 Feb 2012 13:37:36 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-10.tower-21.messagelabs.com with SMTP; 8 Feb 2012 13:37:36 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-17-4f328697e5d4 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id F8.BD.03709.796823F4; Wed, 8 Feb 2012 16:28:39 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 8 Feb 2012 15:37:35 +0200 From: Alexander Vainshtein To: Loa Andersson , "mpls@ietf.org" Date: Wed, 8 Feb 2012 15:37:33 +0200 Thread-Topic: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm Thread-Index: AczmZR1CUVZIa++7QiqeihCEs8lyFQAAWnGQ Message-ID: References: <4F327811.1000700@pi.nu> In-Reply-To: <4F327811.1000700@pi.nu> 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-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa0wTWRjN7bRlWhkzVGsvxGTHUckGhbT4yBApcVdNqomhu+r+2B/rjp1r O7GdTmYGtaiR+MAsuxrRGmMBQQNYUdcgf/ARjZj4igRNfKCiKOKrohDi2wjOdCrL/jv3O+d8 57sz38Ux2wdzFs4LCpIENkibrcbdicG3uXvL84ud/35yMh//6cSYoZpqjLnXcNjEfI3fNDL3 o5vAXJMn+qXZ5Kmv/2Tw3Nl0K80TbzkMPLG95Wav6fcyUMgKQlhhFURxSPa5aa/Er2Z9EZri OTftoikxyPpQCAmKm2ZFEQkcXWQtVIu8QCHBF+Z4we+mFy4pzmWYWQW5Lrooe7Jrxhzr0gAv Uyg3xPJBKoRkmfUjSq1o8wsc4qiVYYlSAoiS/tyNBboTW9LES5a1z06+w8pAZVoFsOCQnAmP vepJ4Qnw+sPj5gpgxW3kOQBbuv9KHfYA2LjrmVlTmUk3PHHkQRKPJ4tgc2IIaBgjRdh+8kiy k5GcAvt7mowaHkfOhw8a6oCuXwDjTXdNOs6HiWvbMQ0T5C+w9s37ZN2mesv3nU16LeRUOLCz KlkH6nQfrh416FkOeK+31qBPTcL6Mx2Yju3w5ZOhlN4Ou7YdT802HdadHjTreBpsPPAqlZsB r+zrNereTHg+3mncCRyxURGxUfbYKHtslL0OGJuAnQ+KyoqQ3+nKQz5eQUGU5wuHTgB9hZ63 gs+1U9oAiQM6nXgx4Cq2mdjVciTUBjJxA20n7JH8YtvYFWEuEmDlwHKpJIjkNgBxjB5PNPyq ygmOjZQiKfydYtSvXIlljfGFtZ+tLJ/hdP7vQDuIp76+xTbSr27dKoREJH23TsRxGhIdWmKG hPxo7Uo+qPxHG3CLlpyuJrdrGkIW2ZDM+3X+KpiU5SBuaASpEYESYcSrvZeNw8PDCeBQ7zmO 6NNU6eo2jrgTamOD2pgzaFeS1RcxQmWVAXO0+seMeY0FzZaCkn5vvHzPfnHZqZazP2yv8kxg Nr+GBy8Wrv8tUnptNrOOq+0q/aOC7vVm1PR05GTnhOYMdA0telEVvRIsW/No65fB8M+XA2O+ Rjdk3+7mosrdlp+mzz3Ub2ndVtmeuaO69e/Tr/Mavd19De96Llgvdi7sfbzl1I2jtFEOsK4c TJLZb+Be3IMKBAAA Cc: Ross Callon Subject: Re: [mpls] 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: Wed, 08 Feb 2012 13:37:40 -0000 Yes/support. Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Wednesday, February 08, 2012 3:27 PM > 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 > Subject: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm > > 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From kishoret@juniper.net Wed Feb 8 07:34: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 61D0E21F85EF for ; Wed, 8 Feb 2012 07:34:43 -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=[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 YgATIvBLO5QS for ; Wed, 8 Feb 2012 07:34:40 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 998F721F85B6 for ; Wed, 8 Feb 2012 07:34:31 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTzKWBsx+Fxl7KjxS8ec80IuGgppHiP0H@postini.com; Wed, 08 Feb 2012 07:34:39 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 Feb 2012 07:33:11 -0800 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; Wed, 8 Feb 2012 10:33:10 -0500 From: Kishore Tiruveedhula To: Kamran Raza , Lizhong Jin , "pranjal.dutta@alcatel-lucent.com" , "vishwas.ietf@gmail.com" , "mustapha.aissaoui@alcatel-lucent.com" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" , "shane@castlepoint.net" , "bedard.phil@gmail.com" Date: Wed, 8 Feb 2012 10:33:09 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlU+vrnSqQEu4oc0qYFtfJC+trqQBIYYjg 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_A0F87AA600EF73468BA3741CFF49DE4F0366EEE197A3EMBX01WFjnp_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 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, 08 Feb 2012 15:34:43 -0000 --_000_A0F87AA600EF73468BA3741CFF49DE4F0366EEE197A3EMBX01WFjnp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think, if new IPv6 family TLV added in the Hello message, then you do= n't need to send separate hello for IPv6. It is kind of combining both Ipv= 4 and Ipv6 hellos into single Hello. I think draft should allow the flexibility of having separate LDP sessions = (Ipv4 and Ipv6 sessions) or single LDP session, so that operator can choose= the option. Thanks, Kishore From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kam= ran Raza Sent: Monday, February 06, 2012 11:50 PM To: Lizhong Jin; pranjal.dutta@alcatel-lucent.com; vishwas.ietf@gmail.com; = mustapha.aissaoui@alcatel-lucent.com Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong, Using single adj [ and just checking local interface enabling for given AF = + capabilities ] will not suffice/work because: 1. LDP capabilities are advertised on peer/session level and do not corres= pond to adj capabilities. 2. An LSR must not be forwarding MPLS on an interface unless/until it has = got an MPLS adj on it - extending the same to address families, an LSR must= not forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [= Single adj will not convey us remote node's interface capability for given= AF, and it will be incorrect to forward 6 MPLS labelled traffic on it unle= ss we know that remote intf is v6 MPLS enabled ] My 2 cents. -- Kamran On 12-02-06 10:22 PM, "Lizhong Jin" wrote: Hi, I wonder if it is feasible to use LDP capability to advertise IPv6 FEC with= out IPv6 adjacency, and only use one adjacency for LDP session in dual-stac= k network. LDP capability is per node capability, not per interface capabil= ity. But for LDP to choose the correct downstream session and output interf= ace for each FEC, it should also check if the output interface is LDP enabl= ed or not. The link adjacency could be used to assist such kind of checking= . [Kamran]: 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 32= bit 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 impac= ts. > > Thanks, > Pranjal > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e 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 th= e 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 --_000_A0F87AA600EF73468BA3741CFF49DE4F0366EEE197A3EMBX01WFjnp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-= 06

    I think= , if new IPv6 family TLV added in the Hello message, then you don’t n= eed to send separate hello for IPv6.  It is kind of combining both Ipv= 4 and Ipv6 hellos into single Hello.

&= nbsp;

I think draft should allow the flexibility= of having separate LDP sessions (Ipv4 and Ipv6 sessions) or single LDP ses= sion, so that operator can choose the option.

 

Thanks,

Kishore

 

From: mpls-bounces@ietf.org [mailt= o:mpls-bounces@ietf.org] On Behalf Of Kamran Raza
Sent: Mo= nday, February 06, 2012 11:50 PM
To: Lizhong Jin; pranjal.dutta@a= lcatel-lucent.com; vishwas.ietf@gmail.com; mustapha.aissaoui@alcatel-lucent= .com
Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on = draft-ietf-mpls-ldp-ipv6-06

 

Hi= Lizhong,

Using single adj [ and just checking local interface enabl= ing for given AF + capabilities ] will not suffice/work because:

&nb= sp;1. LDP capabilities are advertised on peer/session level and do not corr= espond to adj capabilities.
 2. An LSR must not be forwarding MPLS = on an interface unless/until it has got an MPLS adj on it – extending= the same to address families, an LSR must not forward MPLS v6 on an interf= ace unless it has got MPLS v6 adj on it. [ Single adj will not convey us re= mote node’s interface capability for given AF, and it will be incorre= ct to forward 6 MPLS labelled traffic on it unless we know that remote intf= is v6 MPLS enabled ]

 My 2 cents.
-- Kamran

On 12-02= -06 10:22 PM, "Lizhong Jin" <lizhong.jin@zte.com.cn> wrote:


Hi,
I wonder if it is feasible to us= e 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 c= orrect downstream session and output interface for each FEC, it should also= check if the output interface is LDP enabled or not. The link adjacency co= uld be used to assist such kind of checking.

[Kamran]:

Howev= er, 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 L= SR-ID for IPv6 with IPv4, but I prefer new format of LSR-ID.

Regard= s
Lizhong


> --------------------------------------------= --------------------------
>
> Message: 1
> Date: Tue, 7= Feb 2012 05:28:21 +0530
> From: "Dutta, Pranjal K (Pranjal)&quo= t; <pranjal.dutta@alcatel-l= ucent.com>
> To: Vishwas Manral <vishwas.ietf@gmail.com>
> Cc: "Aissaoui, Mustaph= a \(Mustapha\)"
>    <mustapha.aissaoui@alcatel-lucent.com>, &nbs= p;"mpls@ietf.org"
>  &nb= sp; <mpls@ietf.org>
> Subjec= t: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> Message-ID:>    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBAN= SXCHMBSA3.in.
> alcatel-lucent.com>
>    =
> Content-Type: text/plain; charset=3D"us-ascii"
> <= br>> I would rather for complete separation with multiple lsr-id because=
> 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 an= d IPV6.
> Having IPV4 and IPV6 specific hello adjacencies over a link= would
> only decide whether such a link is to be programmed for IPV= 4 or IPV6
> egress traffic but I see it as overkill and unnecessary s= calability impacts.
>
> Thanks,
> Pranjal
>
--------------------------------------------------------
ZTE Informati= on Security Notice: The information contained in this mail is solely proper= ty of the sender's organization. This mail communication is confidential. R= ecipients named above are obligated to maintain secrecy and are not permitt= ed 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<= /p>


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


= --_000_A0F87AA600EF73468BA3741CFF49DE4F0366EEE197A3EMBX01WFjnp_-- From lberger@labn.net Wed Feb 8 08:15: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 345D921F8798 for ; Wed, 8 Feb 2012 08:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.471 X-Spam-Level: X-Spam-Status: No, score=-98.471 tagged_above=-999 required=5 tests=[AWL=1.690, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, 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 gnEPTgETIo2F for ; Wed, 8 Feb 2012 08:15:43 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id BDF2921F876A for ; Wed, 8 Feb 2012 08:15:43 -0800 (PST) Received: (qmail 1769 invoked by uid 0); 8 Feb 2012 16:15:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 8 Feb 2012 16:15:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=UkOvKr12prxwLn+M9HJOAYRPk32GCkQ/ORtuC+cVPAo=; b=CVA+VnSFLHMdAOUdMAItMQ9aIT3TKeY2SB8pHJdWqWr0rtKxdR9EtuVsvv/46n1yX1LwdWl+uvPOwWvcYkq+ubewVMe+LYHoXI92WMn64vEzK9ULY+Zx4iNLGWlzQh8g; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RvABJ-00006y-IN; Wed, 08 Feb 2012 09:15:41 -0700 Message-ID: <4F329FA9.2070707@labn.net> Date: Wed, 08 Feb 2012 11:15:37 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Mach Chen References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> <4F31285C.6040107@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] [CCAMP] Discussion on how to carry the Global_ID 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, 08 Feb 2012 16:15:45 -0000 Mach, Sounds like a good discussion to have with the authors of RFC6370... Lou On 2/7/2012 8:17 PM, Mach Chen wrote: > Hi Lou, > > I am always assume that the Z9-tunnel-num equals to A1-tunnel-num > (for co-routed bidirectional LSP). The motivation (from the text of > RFC6370 and the past discussion on MPLS-TP identifier) of two > tunnel-nums is for simplifying associated bidirectional signaling, > for co-routed bidirectional LSP, two tunnel-nums are unnecessary. If > I am wrong, please correct me.(cc MPLS WG) > > IMHO, the simplest way is to explicitly clarify that for co-routed > bidirectional LSP, A1-tunnel-num=Z9-tunnel-num, maybe a clarification > errata is needed for RFC6370. > > Best regards, Mach > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >> Lou Berger >> Sent: Tuesday, February 07, 2012 9:34 PM >> To: Francesco Fondelli >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] Discussion on how to carry the Global_ID >> >> Francesco, >> From my perspective, the (minimum) requirements are being driven by >> rfc6370. Take a look at sections 5.2 and 5.3, and see if you still think >> more mechanisms are being defined than is necessary. >> >> Lou >> >> On 2/7/2012 3:56 AM, Francesco Fondelli wrote: >>> >>> Am I the only one here that feels "uncomfortable" with this approach and >>> this additional Z9-Tunnel_Num index in GMPLS flying from egress to >>> ingress (for no reason?!?)? It might be naive or even stupid but I'd >>> like to understand why we have to add another index... please shed some >>> light on me. >>> >>> [I'm talking about co-routed bidi, I don't care about associated] >>> >>> thank you >>> ciao >>> FF >>> >>> 2012/2/7 > >>> >>> >>> Vero >>> >>> Why is tunnel number not known by node A? The tunnel number should >>> has been carried in Session and Sender Template/Filter Spec object >>> and exchanged by node A and node Z during the LSP set-up. Correct me >>> if I am wrong. >>> >>> According to the description of RFC6370, section 5.1 >>> At each end point, a tunnel is uniquely identified by the end point's >>> Node_ID and a locally assigned tunnel number. Specifically, a >>> "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique >>> within the context of the Node_ID. The motivation for each end >> point >>> having its own tunnel number is to allow a compact form for the >>> MEP_ID. >>> >>> Which means that for co-routed bidrectional LSP, there are two >>> tunnel numbers, one is locally assigned at node A and the other is >>> locally assigned at node Z. >>> If the signaling message is initialized at node A, the tunnel number >>> carried in Session/Sender Template objects is locally assigned at >>> node A. Of course, a new >>> C-type,like type=8, can be defined in the class of SESSION to carry >>> back the tunnel number assigned at node Z; but according to the >>> discussion with George, I do not think it is a good idea which is >>> not backward compatible. >>> >>> Regards >>> >>> Fei >>> >>> >>> *Vero Zheng > >* >>> >>> 2012-02-07 15:33 >>> >>> >>> 收件人 >>> "zhang.fei3@zte.com.cn " >>> > >>> 抄送 >>> "ccamp@ietf.org " >> > >>> 主题 >>> RE: [CCAMP] Discussion on how to carry the Global_ID >>> >>> >>> >>> >>> >>> >>> >>> >>> Fei, >>> >>> Please see in-line. >>> >>> BR, >>> Vero >>> >>> Fei, >>> >>> you wrote: >>> >>> First, >>> “2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 >>> >>> The Global_ID Object and the ICC_Operator_ID Object are defined in >>> this draft, which describes the procedure of corouted bidirectional >>> LSP (associated bidirectional LSP is not covered in the current >>> version) and requires that the same format( Global_ID or >>> ICC_Operator_ID)is used along the LSP. >>> >>> Which is not true. The Object we defined could be carried in both >>> Path/Resv message, and is not restricted either to co-routed >>> bi-directional LSP or associated bi-directional LSP. >>> >>> >>> Although either co-routed or associated bidirectional LSP is not >>> mentioned in this draft , according to the descripition in section >>> 2.3, " If the node agrees, it MUST use the same format of Operator >>> ID. The same C-Type of OIO MUST be carried in the Resv message", >>> which means that the procedure is for corouted bidrectional LSP. >>> The above is just my understanding and provided for discussion, and >>> if it is wrong or inaccurate, please let me know. >>> >>> The procedure described above aims to guarantee the sender and the >>> receiver using the same C-Type of the object, i.e. both end using >>> Global_ID or both using ICC_Operator_ID. >>> >>> Second, >>> 3. >>> >> http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-0 >> 1 >>> >>> >>> The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which >>> will appear in the Path/Resv message of corouted bidrectional LSP >>> and only appear in the Path message of associated bidirectional LSP. >>> Furthermore, this draft defined a Connection TLV used to carry the >>> local tunnel number assigned at Z9 nodes in the scenario of corouted >>> bidirectional LSP. >>> >>> Why “tunnel number” is carried in the Connection TLV? I don't see >>> its necessary for both co-route/ associated bi-directional LSP. >>> Could you explain? >>> >>> >>> As I said, it is useful for corouted (not associated) bidirectional >>> LSP, consider that there is one LSP (LSP1, initiated at node A) >>> between node A/Z. >>> If the CC-V pakcet is sent from node Z, the MEP_ID of node Z will >>> be inserted in the OAM packets, which is organized by >>> node_ID::tunnel_num::LSP_num >>> (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not >>> pre-stored at node A, it can not judge whether this MEP_ID is valid. >>> See the description in section 5.1.1.2 >>> (*Mis-Connectivity Defect*) of RFC6371. >>> LSP1 >>> A-------------------------------Z >>> >>> >>> >>> Why is tunnel number not known by node A? The tunnel number should >>> has been carried in Session and Sender Template/Filter Spec object >>> and exchanged by node A and node Z during the LSP set-up. Correct me >>> if I am wrong. >>> >>> BR, >>> Vero >>> >>> Thanks. >>> >>> Vero >>> >>> * >>> From:* ccamp-bounces@ietf.org >>> [mailto:ccamp-bounces@ietf.org ] >> *On >>> Behalf Of *zhang.fei3@zte.com.cn * >>> Sent:* Sunday, January 29, 2012 5:50 PM* >>> To:* ccamp@ietf.org * >>> Subject:* [CCAMP] Discussion on how to carry the Global_ID >>> >>> >>> Hi CCAMPers >>> >>> As discussed in the last IETF meeting and mailinglist, the Global_ID >>> should be carried in the signaling messages. One reason is that the >>> judgement of a mis-connectivity defect needs the A1/Z9 nodes to >>> pre-store each other's MEP_ID, whose format is: >>> Gobal_ID+Node_ID+Tunnel_num+LSP_num. >>> >>> Fortunately, there are several drafts related to this topic now, >>> >>> 1. http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01. >>> >>> The Globa_ID is incorporated into the ASSOCIATION object in the >>> current version, which guarantees that the association is global >>> unique. Since the ASSOCIATION object is used across different LSPs, >>> just my2cents, the defined format is deficient to handle more >>> scenarios. For example: >>> >>> (1) Considering a corouted bidirectional LSP, which is not >>> protected by other LSPs through control plane and/or does not share >>> the same resoures with other LSPs. In these cases, the ASSOCIATION >>> object will not be carried in the sigaling messages. >>> >>> (2) Considering an associated bidirectional LSP, although the >>> ASSOCIATION object is carried in the sigaling messages, the >>> global_ID incorporated in the ASSOCIATION object only >>> indicates the global prefix of the A1 or Z9 nodes. If this LSP is >>> across different domains, I think the current format is also >>> deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does >>> not know the global ID of A1 ). >>> >>> 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 >>> >>> The Global_ID Object and the ICC_Operator_ID Object are defined in >>> this draft, which describes the procedure of corouted bidirectional >>> LSP (associated bidirectional LSP is not covered in the current >>> version) and requires that the same format( Global_ID or >>> ICC_Operator_ID)is used along the LSP. >>> >>> 3. >>> >> http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-0 >> 1 >>> >>> >>> The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which >>> will appear in the Path/Resv message of corouted bidrectional LSP >>> and only appear in the Path message of associated bidirectional LSP. >>> Furthermore, this draft defined a Connection TLV used to carry the >>> local tunnel number assigned at Z9 nodes in the scenario of corouted >>> bidirectional LSP. >>> >>> >>> The above materials only provide the rough background. >>> >>> >>> Hope to hear the opinions from the WG that how to carry the >>> Global_ID, then move the work forward. >>> >>> >>> Best regards >>> >>> ;) >>> >>> Fei >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp From pranjal.dutta@alcatel-lucent.com Wed Feb 8 09:14: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 45C5E21F862B for ; Wed, 8 Feb 2012 09:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.848 X-Spam-Level: X-Spam-Status: No, score=-7.848 tagged_above=-999 required=5 tests=[AWL=-1.250, 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 9XIhRv1gzGmr for ; Wed, 8 Feb 2012 09:14:10 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 735E321F86C9 for ; Wed, 8 Feb 2012 09:14:10 -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 q18HDOqt001438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Feb 2012 11:13:28 -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 q18HDN0j006932 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Feb 2012 22:43:23 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 8 Feb 2012 22:43:22 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Lizhong Jin Date: Wed, 8 Feb 2012 22:43:20 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczmCP8ifKcVoZcfRiW2ZQaHIZdAawAe5HIw 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_C584046466ED224CA92C1BC3313B963E09EFF4BE6FINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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: Wed, 08 Feb 2012 17:14:14 -0000 --_000_C584046466ED224CA92C1BC3313B963E09EFF4BE6FINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, adjacency specific capability exchange in hello would be right approac= h for IPV4 + IPV6 and need to extend the work of RFC 5561. The ldp-ipv6 draft should change the text on multiple adjacency behaviour o= n dual stack and should refer to the per adjacency specific ldp capabilities. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Tuesday, February 07, 2012 6:25 PM To: Dutta, Pranjal K (Pranjal) Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); Kamran Raza; vishwas.ietf= @gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, See inline below. Thanks Lizhong "Dutta, Pranjal K (Pranjal)" wrote 2012/= 02/08 02:40:31: > Hi, > Using separate adjacency to decide capabilities on an > interface would kick start several wars as the issue not just > limited to IPV4 vs IPV6. The same is applicable to multicast > capabilities as well when an operator may have multiple ECMP links > between two nodes but certain links/cards do not have multicast > capabilities. [Lizhong] Theoretically, you are right. And ususally we assume LDP enabled = interface also support multicast if LDP session is multicast enabled, but y= es, such assumption has risk. > This is just one example and we have more such > capabiities. So as of now such link specific restrictions should be > imposed by local behaviors rather than coupling with adjacency > types. [Lizhong] Restriction checking based on local capability is not enough, and= having capability risk of peer interface. > Otherwise LDP capabilities should be extended to be used in > per interface ldp hello messages where a single adjacency would be > tagged multiple capabilities. [Lizhong] LDP capability based on per adjacency is a feasible approach, and= if that, we need to change RFC5561. > I would believe that is more rightful > approach than maintaining separate hellos adjacencies for each > capability that would grow exponentially at some point. > > Thanks, > Pranjal > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Kamran Raza > Sent: Monday, February 06, 2012 8:50 PM > To: Lizhong Jin; 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 Lizhong, > > Using single adj [ and just checking local interface enabling for > given AF + capabilities ] will not suffice/work because: > > 1. LDP capabilities are advertised on peer/session level and do not > correspond to adj capabilities. > 2. An LSR must not be forwarding MPLS on an interface unless/until > it has got an MPLS adj on it - extending the same to address > families, an LSR must not forward MPLS v6 on an interface unless it > has got MPLS v6 adj on it. [ Single adj will not convey us remote > node's interface capability for given AF, and it will be incorrect > to forward 6 MPLS labelled traffic on it unless we know that remote > intf is v6 MPLS enabled ] > > My 2 cents. > -- Kamran > > On 12-02-06 10:22 PM, "Lizhong Jin" wrote: > > 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. > > [Kamran]: > > 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 > > > > _______________________________________________ > 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 > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e 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 th= e 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_C584046466ED224CA92C1BC3313B963E09EFF4BE6FINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_C584046466ED224CA92C1BC3313B963E09EFF4BE6FINBANSXCHMBSA_-- From pranjal.dutta@alcatel-lucent.com Wed Feb 8 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 8740E21E8017 for ; Wed, 8 Feb 2012 09:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.709 X-Spam-Level: X-Spam-Status: No, score=-7.709 tagged_above=-999 required=5 tests=[AWL=-1.111, 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 TOSq0Z8-nVwz for ; Wed, 8 Feb 2012 09:25:07 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 94AE621F8753 for ; Wed, 8 Feb 2012 09:25:01 -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 q18HOtb5024922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Feb 2012 11:24:57 -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 q18HOqJI007499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Feb 2012 22:54:54 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 8 Feb 2012 22:54:52 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Aissaoui, Mustapha (Mustapha)" , Lizhong Jin , "vishwas.ietf@gmail.com" Date: Wed, 8 Feb 2012 22:54:50 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlR+hW13amK3+CRWyR54u0xbDYrAAYcWrgADccAgA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD55FDAD9@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD55FDAD9@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_C584046466ED224CA92C1BC3313B963E09EFF4BE72INBANSXCHMBSA_" 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, 08 Feb 2012 17:25:08 -0000 --_000_C584046466ED224CA92C1BC3313B963E09EFF4BE72INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes that would be right approach. Changing the LSR-ID would further open mo= re backward compatibility issues with existing implementations. Thanks, Pranjal ________________________________ From: Aissaoui, Mustapha (Mustapha) Sent: Tuesday, February 07, 2012 7: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-i= d need not be an IP address. Most implementations will actually populate th= e field with a /32 address in IPv4 and thus If necessary we could define a = new format to allow the use of /128 IPv6 addresses. 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 with= out IPv6 adjacency, and only use one adjacency for LDP session in dual-stac= k network. LDP capability is per node capability, not per interface capabil= ity. But for LDP to choose the correct downstream session and output interf= ace for each FEC, it should also check if the output interface is LDP enabl= ed 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 32= bit 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 impac= ts. > > Thanks, > Pranjal > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e 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 th= e 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_C584046466ED224CA92C1BC3313B963E09EFF4BE72INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes that would be right approach. Chan= ging the LSR-ID would further open more backward compatibility issues with exist= ing implementations.

 

Thanks,

Pranjal

 

From: Aissaoui, Mustapha (Mustapha)
Sent: Tuesday, February 07, = 2012 7: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 suppor= ted 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 necessar= y we could define a new format to allow the use of /128 IPv6 addresses.

 

Mustapha.

 

From:= = Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Monday, February 06, 2= 012 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 withou= t IPv6 adjacency, and only use one adjacency for LDP session in dual-stack network. LDP capability is per node capability, not per interface capabilit= y. But for LDP to choose the correct downstream session and output interface f= or each FEC, it should also check if the output interface is LDP enabled or no= t. 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 fo= r 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>,   &quo= t;mpls@ietf.org"
>    <mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> Message-ID:
>    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHM= BSA3.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 IP= V6.
> 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 Inf=
ormation Security Notice: The information containe=
d in this mail is solely property of&nbs=
p;the sender's organization. This mail communicati=
on is confidential. Recipients named above ar=
e obligated to maintain secrecy and are =
not permitted to disclose the contents of&nbs=
p;this communication to others.
This em=
ail and any files transmitted with it ar=
e confidential and intended solely for the&nb=
sp;use of the individual or entity to wh=
om they are addressed. If you have recei=
ved this email in error please notify th=
e originator of the message. Any views e=
xpressed in this message are those of th=
e individual sender.
This me=
ssage has been scanned for viruses and S=
pam by ZTE Anti-Spam system.
--_000_C584046466ED224CA92C1BC3313B963E09EFF4BE72INBANSXCHMBSA_-- From zhang.fei3@zte.com.cn Wed Feb 8 18:13: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 84BFC21F85ED; Wed, 8 Feb 2012 18:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.985 X-Spam-Level: X-Spam-Status: No, score=-97.985 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, 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 kld-MKCAOaxM; Wed, 8 Feb 2012 18:13:30 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4882521F84BF; Wed, 8 Feb 2012 18:13:12 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 538291784411434; Thu, 9 Feb 2012 10:08:08 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.5467966663; Thu, 9 Feb 2012 10:13:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q192Cv2r033635; Thu, 9 Feb 2012 10:12:57 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4F327811.1000700@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-KeepSent: B2366300:8B13C3C0-4825799F:0008D0B7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 9 Feb 2012 10:12:52 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-09 10:12:58, Serialize complete at 2012-02-09 10:12:58 Content-Type: multipart/alternative; boundary="=_alternative 000C2B244825799F_=" X-MAIL: mse02.zte.com.cn q192Cv2r033635 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-koike-mpls-tp-temporal-hitless-psm@tools.ietf.org" , mpls-bounces@ietf.org, Ross Callon Subject: Re: [mpls] 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: Thu, 09 Feb 2012 02:13:31 -0000 This is a multipart message in MIME format. --=_alternative 000C2B244825799F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgDQoNCk9uZSBjb21tZW50Og0KDQpJIGRvIG5vdCB0aGluayB0aGUgZGVzY3JpcHRpb25zIGlu IHNlY3Rpb24gNSBhcmUgYWNjdXJhdGU6DQoiUGFja2V0IGxvc3MgYW5kIHBhY2tldCBkZWxheSBt ZWFzdXJlbWVudHMgYXJlIE9BTSBmdW5jdGlvbnMgaW4gd2hpY2ggDQpoaXRsZXNzIGFuZCB0ZW1w b3JhbCBzZWdtZW50IG1vbml0b3JpbmcgYXJlIHN0cm9uZ2x5IHJlcXVpcmVkIGJlY2F1c2UgDQp0 aGVzZSBmdW5jdGlvbnMgYXJlIHN1cHBvcnRlZCBvbmx5IGJldHdlZW4gZW5kIHBvaW50cyBvZiBh IHRyYW5zcG9ydCANCnBhdGguIg0KDQpGb3IgYWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGl2ZSBz Y29wZXMgYXQgdGhlIHNlY3Rpb24gMi45LjUgb2YgUkZDNjM3NCwgDQp0aGUgcGFja2V0IGxvc3Mg YW5kIGRlbGF5IG1lYXN1cmVtZW50IGZ1bmN0aW9ucyBhcmUgbm90IHN0cmljdGx5IGxpbWl0ZWQg DQpvbmx5IGJldHdlZW4gZW5kcG9pbnRzOiANCiJJbiB0aGUgY2FzZSBvZiBhbiBMU1AsIGl0IG1h eSBiZSBkZXNpcmFibGUgdG8gbWVhc3VyZSB0aGUgbG9zcyBvciBkZWxheSANCnRvIG9yIGZyb20g YW4gaW50ZXJtZWRpYXRlIG5vZGUgYXMgd2VsbCBhcyBiZXR3ZWVuIExTUCBlbmRwb2ludHMuICBU aGlzIA0KY2FuIGJlIGRvbmUgaW4gcHJpbmNpcGxlIGJ5IHNldHRpbmcgdGhlIFRpbWUgdG8gTGl2 ZSAoVFRMKSBmaWVsZCBpbiB0aGUgDQpvdXRlciBMU0UgYXBwcm9wcmlhdGVseSB3aGVuIHRhcmdl dGluZyBhIG1lYXN1cmVtZW50IG1lc3NhZ2UgdG8gYW4gDQppbnRlcm1lZGlhdGUgbm9kZSIuDQoN ClNpbmNlIHRoaXMgaXMgYSByZXF1aXJlbWVudCBkb2N1bWVudCBhbmQgaWYgdGhlIGluYWNjdXJh Y3kgZG9lcyBub3QgYWZmZWN0IA0KdGhpcyBkb2N1bWVudCwgcGxlYXNlIGNvdW50ICJ5ZXMvc3Vw cG9ydCIgZnJvbSBtZSB0byBzdXBwb3J0IHRoaXMgDQphZG9wdGlvbi4NCg0KUmVnYXJkcw0KDQpG ZWkNCg0KDQoNCkxvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4gDQq3orz+yMs6ICBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcNCjIwMTItMDItMDggMjE6MjYNCg0KytW8/sjLDQoibXBsc0BpZXRmLm9yZyIg PG1wbHNAaWV0Zi5vcmc+LCBNUExTLVRQIGFkIGhvYyB0ZWFtIA0KPGFobXBscy10cEBsaXN0cy5p dHUuaW50PiwgDQoiZHJhZnQta29pa2UtbXBscy10cC10ZW1wb3JhbC1oaXRsZXNzLXBzbUB0b29s cy5pZXRmLm9yZyIgDQo8ZHJhZnQta29pa2UtbXBscy10cC10ZW1wb3JhbC1oaXRsZXNzLXBzbUB0 b29scy5pZXRmLm9yZz4sIFJvc3MgQ2FsbG9uIA0KPHJjYWxsb25AanVuaXBlci5uZXQ+LCBHZW9y Z2UgU3dhbGxvdyA8c3dhbGxvd0BjaXNjby5jb20+LCBBZHJpYW4gRmFycmVsIA0KPGFkcmlhbkBv bGRkb2cuY28udWs+DQqzrcvNDQoNCtb3zOINClttcGxzXSBQb2xsIG9uIGRyYWZ0LWtvaWtlLW1w bHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1wc20NCg0KDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQoN CnRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIHRvIHNlZSBpZiB0aGVyZSBpcyBzdXBw b3J0IHRvIG1ha2UNCg0KICAgIGRyYWZ0LWtvaWtlLW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1w c20tMDQNCg0KbXBscyB3b3JraW5nIGdyb3VwIGRyYWZ0cy4NCg0KUGxlYXNlZCBzZW5kIHlvdXIg Y29tbWVudHMgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCihtcGxzQGll dGYub3JnKS4NCg0KVGhpcyBwb2xsIGVuZHMgRmVicnVhcnkgMjIsIDIwMTIhDQoNCkxvYQ0KZm9y IHRoZSBtcGxzIHdnIGNoYWlycw0KDQoNCi0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAg ICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQpTciBTdHJh dGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCkVyaWNzc29u IEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDky IDEzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBs cyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KDQoNCg0K --=_alternative 000C2B244825799F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPk9uZSBjb21tZW50OjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+SSBkbyBub3QgdGhpbmsgdGhlIGRlc2NyaXB0aW9ucyBpbiBzZWN0aW9uIDUgYXJlIGFj Y3VyYXRlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7UGFja2V0IGxv c3MgYW5kIHBhY2tldCBkZWxheSBtZWFzdXJlbWVudHMgYXJlDQpPQU0gZnVuY3Rpb25zIGluIHdo aWNoIGhpdGxlc3MgYW5kIHRlbXBvcmFsIHNlZ21lbnQgbW9uaXRvcmluZyBhcmUgc3Ryb25nbHkN CnJlcXVpcmVkIGJlY2F1c2UgdGhlc2UgZnVuY3Rpb25zIGFyZSBzdXBwb3J0ZWQgb25seSBiZXR3 ZWVuIGVuZCBwb2ludHMNCm9mIGEgdHJhbnNwb3J0IHBhdGguJnF1b3Q7PC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Gb3IgYWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGl2 ZSBzY29wZXMgYXQgdGhlIHNlY3Rpb24NCjIuOS41IG9mIFJGQzYzNzQsIHRoZSBwYWNrZXQgbG9z cyBhbmQgZGVsYXkgbWVhc3VyZW1lbnQgZnVuY3Rpb25zIGFyZSBub3QNCnN0cmljdGx5IGxpbWl0 ZWQgb25seSBiZXR3ZWVuIGVuZHBvaW50czogPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mcXVvdDtJbiB0aGUgY2FzZSBvZiBhbiBMU1AsIGl0IG1heSBiZSBkZXNpcmFibGUgdG8N Cm1lYXN1cmUgdGhlIGxvc3Mgb3IgZGVsYXkgdG8gb3IgZnJvbSBhbiBpbnRlcm1lZGlhdGUgbm9k ZSBhcyB3ZWxsIGFzIGJldHdlZW4NCkxTUCBlbmRwb2ludHMuICZuYnNwO1RoaXMgY2FuIGJlIGRv bmUgaW4gcHJpbmNpcGxlIGJ5IHNldHRpbmcgdGhlIFRpbWUNCnRvIExpdmUgKFRUTCkgZmllbGQg aW4gdGhlIG91dGVyIExTRSBhcHByb3ByaWF0ZWx5IHdoZW4gdGFyZ2V0aW5nIGEgbWVhc3VyZW1l bnQNCm1lc3NhZ2UgdG8gYW4gaW50ZXJtZWRpYXRlIG5vZGUmcXVvdDsuPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5TaW5jZSB0aGlzIGlzIGEgcmVxdWlyZW1lbnQgZG9j dW1lbnQgYW5kIGlmIHRoZSBpbmFjY3VyYWN5DQpkb2VzIG5vdCBhZmZlY3QgdGhpcyBkb2N1bWVu dCwgcGxlYXNlIGNvdW50ICZxdW90O3llcy9zdXBwb3J0JnF1b3Q7IGZyb20NCm1lIHRvIHN1cHBv cnQgdGhpcyBhZG9wdGlvbi48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PlJlZ2FyZHM8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkZlaTwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkxv YSBBbmRlcnNzb24gJmx0O2xvYUBwaS5udSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBscy1ib3VuY2VzQGlldGYub3Jn PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDItMDggMjE6 MjY8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssDQpNUExT LVRQIGFkIGhvYyB0ZWFtICZsdDthaG1wbHMtdHBAbGlzdHMuaXR1LmludCZndDssICZxdW90O2Ry YWZ0LWtvaWtlLW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1wc21AdG9vbHMuaWV0Zi5vcmcmcXVv dDsNCiZsdDtkcmFmdC1rb2lrZS1tcGxzLXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtQHRvb2xzLmll dGYub3JnJmd0OywgUm9zcyBDYWxsb24NCiZsdDtyY2FsbG9uQGp1bmlwZXIubmV0Jmd0OywgR2Vv cmdlIFN3YWxsb3cgJmx0O3N3YWxsb3dAY2lzY28uY29tJmd0OywNCkFkcmlhbiBGYXJyZWwgJmx0 O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250 PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bbXBsc10gUG9sbCBvbiBkcmFmdC1rb2lrZS1tcGxz LXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Xb3JraW5nIEdyb3VwLDxicj4NCjxicj4NCnRoaXMg aXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIHRvIHNlZSBpZiB0aGVyZSBpcyBzdXBwb3J0IHRv IG1ha2U8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwO2RyYWZ0LWtvaWtlLW1wbHMtdHAtdGVtcG9y YWwtaGl0bGVzcy1wc20tMDQ8YnI+DQo8YnI+DQptcGxzIHdvcmtpbmcgZ3JvdXAgZHJhZnRzLjxi cj4NCjxicj4NClBsZWFzZWQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcg Z3JvdXAgbWFpbGluZyBsaXN0PGJyPg0KKG1wbHNAaWV0Zi5vcmcpLjxicj4NCjxicj4NClRoaXMg cG9sbCBlbmRzIEZlYnJ1YXJ5IDIyLCAyMDEyITxicj4NCjxicj4NCkxvYTxicj4NCmZvciB0aGUg bXBscyB3ZyBjaGFpcnM8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2Eg QW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3Nv bkBlcmljc3Nvbi5jb208YnI+DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpFcmlj c3NvbiBJbmMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiArNDYgMTAg NzE3IDUyIDEzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOys0NiA3NjcgNzIgOTIgMTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4N Cjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 000C2B244825799F_=-- From koike.yoshinori@lab.ntt.co.jp Wed Feb 8 21:13: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 37F4A21F84CF for ; Wed, 8 Feb 2012 21:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_42=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 mZ7t9+03wXmD for ; Wed, 8 Feb 2012 21:13:01 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBD921F84CE for ; Wed, 8 Feb 2012 21:13:01 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id q195Cxou015188; Thu, 9 Feb 2012 14:12:59 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4AE916B9E; Thu, 9 Feb 2012 14:12:59 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 41E166843; Thu, 9 Feb 2012 14:12:59 +0900 (JST) Received: from [129.60.11.43] (koike-pc.nslab.ecl.ntt.co.jp [129.60.11.43]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q195Cwl9031222; Thu, 9 Feb 2012 14:12:58 +0900 Message-ID: <4F335682.8030904@lab.ntt.co.jp> Date: Thu, 09 Feb 2012 14:15:46 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int Subject: Re: [mpls] 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: Thu, 09 Feb 2012 05:13:02 -0000 Hello Fei, Thank you for your comment. This description is based on MPLS=TP OAM requirements specified in section 2.2.11 and 2.2.12 of RFC5860. We will add the following information in the sentence for clarification when updating the draft, if this works for you. "... because these functions are supported only between end points of a transport path according to RFC5860." Best regards, Yoshinori (2012/02/09 11:12), zhang.fei3@zte.com.cn wrote: > Hi > > One comment: > > I do not think the descriptions in section 5 are accurate: > "Packet loss and packet delay measurements are OAM functions in which > hitless and temporal segment monitoring are strongly required because > these functions are supported only between end points of a transport > path." > > For according to the descriptive scopes at the section 2.9.5 of RFC6374, > the packet loss and delay measurement functions are not strictly limited > only between endpoints: > "In the case of an LSP, it may be desirable to measure the loss or delay > to or from an intermediate node as well as between LSP endpoints. This > can be done in principle by setting the Time to Live (TTL) field in the > outer LSE appropriately when targeting a measurement message to an > intermediate node". > > Since this is a requirement document and if the inaccuracy does not affect > this document, please count "yes/support" from me to support this > adoption. > > Regards > > Fei > > > > Loa Andersson > 发件人: mpls-bounces@ietf.org > 2012-02-08 21:26 > > 收件人 > "mpls@ietf.org", MPLS-TP ad hoc team > , > "draft-koike-mpls-tp-temporal-hitless-psm@tools.ietf.org" > , Ross Callon > , George Swallow, Adrian Farrel > > 抄送 > > 主题 > [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm > > > > > > > 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 > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From Rolf.Winter@neclab.eu Thu Feb 9 06:02: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 2D89221F8603 for ; Thu, 9 Feb 2012 06:02:30 -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=[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 S-GzPSkSVtG4 for ; Thu, 9 Feb 2012 06:02:29 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5479921F85EC for ; Thu, 9 Feb 2012 06:02:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B04D4280001CE for ; Thu, 9 Feb 2012 15:02:28 +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 9QJTQVqWKFwf for ; Thu, 9 Feb 2012 15:02:28 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 94A1428000084 for ; Thu, 9 Feb 2012 15:02:23 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.103]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 9 Feb 2012 15:02:02 +0100 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm Thread-Index: AQHM5mVZm83z1g3UaEOv7jAVlwKTCZY0mcJw Date: Thu, 9 Feb 2012 14:02:01 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D2500298A@PALLENE.office.hd> References: <4F327811.1000700@pi.nu> In-Reply-To: <4F327811.1000700@pi.nu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] 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: Thu, 09 Feb 2012 14:02:30 -0000 Yes/support. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Mittwoch, 8. Februar 2012 14:27 > 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 > Subject: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make >=20 > draft-koike-mpls-tp-temporal-hitless-psm-04 >=20 > mpls working group drafts. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends February 22, 2012! >=20 > Loa > for the mpls wg chairs >=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 From Feng.f.Huang@alcatel-sbell.com.cn Thu Feb 9 16:51: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 C233511E80AD for ; Thu, 9 Feb 2012 16:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.256 X-Spam-Level: X-Spam-Status: No, score=0.256 tagged_above=-999 required=5 tests=[AWL=-1.348, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 qavczWfCa8c4 for ; Thu, 9 Feb 2012 16:51:42 -0800 (PST) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6E32A11E808F for ; Thu, 9 Feb 2012 16:51:32 -0800 (PST) X-AuditID: ac189297-b7b8fae000001b86-17-4f346a118868 Received: from CNSHJCASHUB01.ad4.ad.alcatel.com (Unknown_Domain [135.251.50.71]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id 84.3D.07046.11A643F4; Fri, 10 Feb 2012 08:51:29 +0800 (HKT) Received: from CNSHJMBX01.ad4.ad.alcatel.com ([135.251.50.101]) by CNSHJCASHUB01.ad4.ad.alcatel.com ([135.251.50.71]) with mapi id 14.01.0323.000; Fri, 10 Feb 2012 08:51:29 +0800 From: HUANG Feng F To: Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-koike-mpls-tp-temporal-hitless-psm@tools.ietf.org" , Ross Callon , George Swallow , Adrian Farrel Thread-Topic: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm Thread-Index: AQHM5mVUDSaYZjegA0+BCqovgKr3MpY0BwMA Date: Fri, 10 Feb 2012 00:51:28 +0000 Message-ID: <796B6F5769D3E140A2BC3AAF7AC8D57F08D49E@cnshjmbx01> References: <4F327811.1000700@pi.nu> In-Reply-To: <4F327811.1000700@pi.nu> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.143.56] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] 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, 10 Feb 2012 00:51:44 -0000 WWVzL3N1cHBvcnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IExvYSBBbmRlcnNzb24NClNlbnQ6IDIwMTLE6jLUwjjI1SAyMToyNw0KVG86IG1wbHNAaWV0Zi5v cmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWtvaWtlLW1wbHMtdHAtdGVtcG9yYWwtaGl0 bGVzcy1wc21AdG9vbHMuaWV0Zi5vcmc7IFJvc3MgQ2FsbG9uOyBHZW9yZ2UgU3dhbGxvdzsgQWRy aWFuIEZhcnJlbA0KU3ViamVjdDogW21wbHNdIFBvbGwgb24gZHJhZnQta29pa2UtbXBscy10cC10 ZW1wb3JhbC1oaXRsZXNzLXBzbQ0KDQpXb3JraW5nIEdyb3VwLA0KDQp0aGlzIGlzIHRvIHN0YXJ0 IGEgdHdvIHdlZWsgcG9sbCB0byBzZWUgaWYgdGhlcmUgaXMgc3VwcG9ydCB0byBtYWtlDQoNCiAg ICBkcmFmdC1rb2lrZS1tcGxzLXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtLTA0DQoNCm1wbHMgd29y a2luZyBncm91cCBkcmFmdHMuDQoNClBsZWFzZWQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBt cGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQoobXBsc0BpZXRmLm9yZykuDQoNClRoaXMg cG9sbCBlbmRzIEZlYnJ1YXJ5IDIyLCAyMDEyIQ0KDQpMb2ENCmZvciB0aGUgbXBscyB3ZyBjaGFp cnMNCg0KDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVt YWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJk cyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQpFcmljc3NvbiBJbmMgICAgICAgICAgICAg ICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQpt cGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg== From satoshi.ueno@ntt.com Thu Feb 9 17:10: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 47C1C21F853B for ; Thu, 9 Feb 2012 17:10:11 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 RHpjsjoLZtoN for ; Thu, 9 Feb 2012 17:10:08 -0800 (PST) Received: from mgw3.noc.ntt.com (mgw3.noc.ntt.com [210.160.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id A58CD21F85C2 for ; Thu, 9 Feb 2012 17:10:07 -0800 (PST) Received: from mop1.noc.ntt.com by mgw3.noc.ntt.com (NTT-Com MailSV) with ESMTP id q1A1A6s0017819 for ; Fri, 10 Feb 2012 10:10:06 +0900 (JST) Received: from mip01.noc.ntt.com (mvi1.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0LZ500719KKT1B@ntt.com> for mpls@ietf.org; Fri, 10 Feb 2012 10:10:05 +0900 (JST) Date: Fri, 10 Feb 2012 10:10:04 +0900 From: "Satoshi UENO" In-reply-to: <4F327811.1000700@pi.nu> To: mpls@ietf.org Message-id: <003301cce790$b8e4c8d0$2aae5a70$@ntt.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: ja Content-transfer-encoding: 7bit Thread-index: AQGEX7c4LqRbh0Xto+/T/rid8RYTFJbGYXLA x-ccmail-original-to: mpls@ietf.org References: <4F327811.1000700@pi.nu> Subject: Re: [mpls] 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, 10 Feb 2012 01:10:12 -0000 Yes/support. Best Regards, Satoshi > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, February 08, 2012 10:27 PM > 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 > Subject: Poll on draft-koike-mpls-tp-temporal-hitless-psm > > 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 hideki.endo.es@hitachi.com Thu Feb 9 19:11: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 4262D11E8075 for ; Thu, 9 Feb 2012 19:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 agEUHsoVSJJY for ; Thu, 9 Feb 2012 19:11:53 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id A0DD221F8469 for ; Thu, 9 Feb 2012 19:11:52 -0800 (PST) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id E207237AC6 for ; Fri, 10 Feb 2012 12:11:51 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id q1A3BpYg007058; Fri, 10 Feb 2012 12:11:51 +0900 Received: from vshuts2.hitachi.co.jp (vshuts2.hitachi.co.jp [10.201.6.71]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q1A3BpqD022350 for ; Fri, 10 Feb 2012 12:11:51 +0900 X-AuditID: b753bd60-9825fba00000359c-5f-4f348af69492 Received: from gmaxml15.clb.hitachi.co.jp (unknown [158.213.157.135]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id E23EC8B0331 for ; Fri, 10 Feb 2012 12:11:50 +0900 (JST) Received: from [127.0.0.1] by gmaxml15.clb.hitachi.co.jp (Switch-3.1.9/Switch-3.1.9) id 41A31BEIM000034D8; Fri, 10 Feb 2012 12:11:50 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Fri, 10 Feb 2012 12:11:35 +0900 References: <4F327811.1000700@pi.nu> Priority: normal Importance: normal X400-Content-Identifier: X4F348AE100000M X400-MTS-Identifier: [/C=JP/ADMD=GMGROUP/PRMD=GMGROUP/;mta16120210121129L8U] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] 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, 10 Feb 2012 03:11:54 -0000 Yes/support. BR, Hideki >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 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From huubatwork@gmail.com Fri Feb 10 03:12: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 A0C0121F86A7 for ; Fri, 10 Feb 2012 03:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TyfcBPV-9Jlg for ; Fri, 10 Feb 2012 03:12:10 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E271E21F86A6 for ; Fri, 10 Feb 2012 03:12:09 -0800 (PST) Received: by eaal12 with SMTP id l12so889449eaa.31 for ; Fri, 10 Feb 2012 03:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8WMsi02mjCAKOxITa9kzeqlEhejq4ESReN3fK5mIt68=; b=HKi/IWg8zGgJfcqRRWZr77dMHDrvpumiBwA1a9DzdwdnDASCIZWSrgRF+24v+EAnGl jrQ6JCOqo3f2O4XRjuDnbI0MmMeVrmiK/0OtYyc4xBtMKplS0d/CQtMoDATZ5UsgzwMR 8FHuygdse8K4u8evbdcA24LJcWqSAiM9bN8+s= Received: by 10.14.45.75 with SMTP id o51mr1920964eeb.20.1328872329037; Fri, 10 Feb 2012 03:12:09 -0800 (PST) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id n58sm20901553een.10.2012.02.10.03.12.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 03:12:07 -0800 (PST) Message-ID: <4F34FB85.8090102@gmail.com> Date: Fri, 10 Feb 2012 12:12:05 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <4F327811.1000700@pi.nu> In-Reply-To: <4F327811.1000700@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 11:12:10 -0000 Support! Regards, Huub. ============= On 08-02-12 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 > > From eric.gray@ericsson.com Fri Feb 10 11: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 C9FF221F8743 for ; Fri, 10 Feb 2012 11:24:06 -0800 (PST) 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 4sDEPDMWlkTE for ; Fri, 10 Feb 2012 11:24:05 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A416621F8712 for ; Fri, 10 Feb 2012 11:24:04 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1AJNibA007510 for ; Fri, 10 Feb 2012 13:24:04 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 10 Feb 2012 14:24:00 -0500 From: Eric Gray To: "mpls@ietf.org" Date: Fri, 10 Feb 2012 14:23:57 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlTW1qeaF4gzFJRE+nxkXXbtwYMQC2+KQQ Message-ID: 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: [mpls] FW: 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, 10 Feb 2012 19:24:06 -0000 Forwarded in plain text... ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 11:03 PM To: Dutta, Pranjal K (Pranjal) Cc: Kishore Tiruveedhula; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Pranjal, They would definitely share fate if we used one session. However if we used just one adjacency, we would loose a functionality of He= llo's that of verifying peer connectivity. Do you think it is not critical = in such a case? Thanks, Vishwas On Mon, Feb 6, 2012 at 6:50 PM, Dutta, Pranjal K (Pranjal) wrote: Yes, that's what I suggested. However it won't solve the concerns r= aised by Shane and Phil since IPV4 + IPV4 tunnels would fate share over sin= gle ldp session. The solution to that can be separation of lsr-ids for IPV4= and IPV6 sessions between same peers. Thanks, Pranjal ________________________________ From: Kishore Tiruveedhula [mailto:kishoret@juniper.net] Sent: Monday, February 06, 2012 6:29 PM To: Vishwas Manral; Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 How about defining new IPv6 capability Parameter TLV, which can be = sent in the Init message, instead of maintaining two separate Ipv4 and Ipv6= adjacencies for single link? Thanks, Kishore From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behal= f Of Vishwas Manral Sent: Monday, February 06, 2012 7:03 PM To: Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Good points Pranjal. The idea is simple, the current specs allow multiple adjacencies an= d still have a single session. We are allowing IPv4 and IPv6 adjacencies to= check forwarding is working and then use only one session, based on what t= he operator prioritizes the Address family usage. It is very similar to the= usecase of multiple parallel links, between the same set of devices exampl= e as given in RFC 5036. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) wrote: 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 shar= ing would continue over the single ldp/tcp session for IPV4 and IPV6. Having IPV4 and IPV6 specific hello adjacencies over a link would o= nly 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 ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 3:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@= ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we= want complete separation. Ofcourse the assumption is we will have all adja= cencies using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) wrote: That means in mobility backhauls if we are running 10K adjacencies = today, this draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shan= e Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using d= ifferent instances of LDP itself or something in between, in which case we = can use different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we c= an currently support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard wrote: I understand the road LDP has gone down with regards to using a sin= gle session/adjacency to advertise multiple families of FECs, similar t= o BGP. Like I said, many providers these days have taken steps to separate= their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational fo= lks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two diff= erent sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilitie= s for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" wrote: >I second to Mustapha. Further, we had already started LDP capabili= ties >based approach on various FEC types support over a single LDP sess= ion >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is= not a >sound approach and would raise other questions such as which adjac= ency to >be >used for various mLdp fec types etc (as some of those has mix of i= pv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beha= lf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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 tupl= e >{LSR-id, label-space-id}. If two LSR nodes using the same LSR-id w= ant to >advertise two different label spaces, then they must use two diffe= rent >Hello adjacencies and LDP sessions for that. Also, if an implement= ation >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 F= EC >which are carried. For example, the same LDP Hello Adjacency and L= DP >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 I= Pv4 on >an IPv4 session between two LSRs, then we should consider extendi= ng RFC >5036 to allow for two different LSR-id values sharing the same glo= bal >label space. This way, we can have separate Hello adjacency and LD= P >session and it is up to the user to assign which FEC type is allow= ed on >which LDP session. This is a new work item but in my view much cle= aner >and backward compatible with RFC 5036 than to try to tie the addre= ss >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 inpu= t 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 e= ach >address family. (If my impression is incorrect I apologize). > >I actually *do* want to have separate LDP Hello and Session adjace= ncies: >one per address family, at least at this point in time. I'm concer= ned >about [operational] issues that may develop in, for example, v6 af= fecting >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 im= proving >the robustness of IPv6 ND to DoS attacks. There are potentially ot= her >areas where IPv6 will be hardened, as well. The bottom-line is I d= o not >want problems in v6 to affect exchange of FEC's + labels for v4, o= r >vice-versa. Also, FWIW, there has already been a precedent here wr= t BGP >where there it maintains separate neighbors/sessions for each addr= ess >family, so why aren't we doing the same thing for LDP? > >Ultimately, having separate sessions over-the-wire is much more in= tuitive >to operators in lots of cases where they may expect that a configu= ration >change or bugs they /think/ are only going to affect one address f= amily, >really do only affect one address family. Besides, LDP Hello & Ses= sions >timers, when set to default, are extremely relaxed (order of sever= al >seconds), so the burden on implementations to maintain separate se= ssions >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 shar= e 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 m= ailing >>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 referri= ng 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 sh= ould >>explicitly refer to /128 for IPv6. >> >> >> 2. Section 3 - LSP Mapping; last Paragraph: >> " >> Additionally, it is desirable that a packet is forwarded to an L= SP of >>an egress router, only if LSP's address-family (e.g. LSPv4 or LSP= v6) >>matches with that of the LDP hello adjacency on the next-hop inte= rface. >> " >> 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 stat= ement >>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 theref= ore >> updates that sentence to the following: "For a given address f= amily >> over which a Hello is sent, and a given label space, an LSR MU= ST >> advertise the same transport address." This rightly enables th= e 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 th= at >>advertise the same label space. In fact the intent as explained i= n the >>second sentence of that same paragraph was to make sure that if t= wo LSRs >>are establishing multiple Hello adjacencies that they play the sa= me >>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 wor= ks 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 messa= ges >>over a dual-stack interface since there could be both IPv4 and IP= v6 LSRs >>on the same subnet. However, this does not justify the need to ma= intain >>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 interfa= ce, >>whichever came up first. Over a P2P interface, it is up to the us= er 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 IPv= 4 >> 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 me= ssage >>is processed. >> >> >> 6. Section 6.1 - Transport connection establishment " >> 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a n= ew >> LDP session with a remote LSR, if it has both IPv4 and IP= v6 >> hello adjacencies for the same LDP Identifier (over a dua= l- >> stack interface, or two or more single-stack IPv4 and IPv= 6 >> interfaces). This applies to the section 2.5.2 of RFC5036= . >> >> 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a n= ew >> 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 adjac= ency 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 p= eer >> 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 bind= ings >>should depend on the existence of an IPv6 Hello adjacency. This i= s 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 multica= st LDP >>(mLDP) FECs. >> >> >> 8. Section 7 - Label Distribution; Fourth paragraph: >> " >> Additionally, to ensure backward compatibility (and interoperabi= lity >> with IPv4-only LDP implementations), this document specifies tha= t >> - 1. An LSR MUST NOT send a label mapping message with a FEC TLV >>containing FEC Elements of different address-family. In other wor= ds, a >>FEC TLV in the label mapping message MUST contain the FEC Element= s >>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 diff= erent >>address-family. In other words, an Address List TLV in the Addres= s (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 sufficien= t. >>Although implementations don't mix and match FEC elements but the= y 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 r= eceived >>from two different peers is not a new issue. It needed to be hand= led in >>existing IPv4 based LDP implementations. Maybe the authors can sp= ecify >>why duplicate link local addresses is any different. >> >> >> 10. Section 9 - LDP TTL Security >> " >> This document also specifies that the LDP/TCP transport connecti= on >> over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Secu= rity >> Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LD= P >> session peering established between the adjacent LSRs using Ba= sic >> Discovery, by default. >> " >> MA> GTSM must be optional as explained in RFC 5082. This draft i= s not >>defining a new protocol and as such it should remain optional as = in RFC >>5036. >> From eric.gray@ericsson.com Fri Feb 10 11:24: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 D824121F87B4 for ; Fri, 10 Feb 2012 11:24:09 -0800 (PST) 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 9QbY69awyMLp for ; Fri, 10 Feb 2012 11:24:08 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6922421F8733 for ; Fri, 10 Feb 2012 11:24:05 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1AJNibD007510 for ; Fri, 10 Feb 2012 13:24:05 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 10 Feb 2012 14:24:02 -0500 From: Eric Gray To: "mpls@ietf.org" Date: Fri, 10 Feb 2012 14:23:59 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlK+FRTKfoWnKcSjm2S9uK5BvsqQACTSMLAABqwUAAvIkXEA== Message-ID: 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: [mpls] FW: 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, 10 Feb 2012 19:24:10 -0000 Forwarded in plain text... ________________________________ From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] Sent: Monday, February 06, 2012 8:28 PM To: Aissaoui, Mustapha (Mustapha); 'vishwas.ietf@gmail.com' Cc: 'bedard.phil@gmail.com'; 'shane@castlepoint.net'; 'mpls@ietf.org' Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Yes, LDP hello adjacency has no relation ship with fec types advertised - t= hat's an exclusive capability of the ldp session only. Multiple link hello adjacency defines ECMP programming behaviour only. On t= heory/paper there may not be a difference between 10K and 20K hello adjacencies but in reality it matters a lot on im= plementations. I don't see any strong technical reason for separate hello adjacencies for IPv4 and IPV6, rather go for separate ||= LDP sessions between two peers for better fec type demux behaviour/alleviate shared-fate concerns etc. Thanks, Pranjal ________________________________ From: Aissaoui, Mustapha (Mustapha) Sent: Monday, February 06, 2012 5:09 PM To: 'vishwas.ietf@gmail.com'; Dutta, Pranjal K (Pranjal) Cc: 'bedard.phil@gmail.com'; 'shane@castlepoint.net'; 'mpls@ietf.org' Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 There is actually a fundamental difference between the parallel links in RF= C 5036 and this proposal. The tie introduced between any of the Hello adjac= encies and the FEC type advertised. In LDP so far this is controlled by per= -peer prefix policies and LDP capability. If the intent is to provide some level of control plane separation, as expl= ained by Shane and Phil, then we would need separate Hello adjacencies and = separate LDP sessions and let users decide what FEC types they want to use = for each. There is no point of creating a hybrid scheme which doubles the n= umber of adjacencies and changes the LDP state machine for no apparent gain= . Mustapha. Sent from my Blackberry! ________________________________ From: Vishwas Manral To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard ; Aissaoui, Mustapha (Mustapha); Sha= ne Amante ; mpls@ietf.org Sent: Mon Feb 06 18:03:09 2012 Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Good points Pranjal. The idea is simple, the current specs allow multiple adjacencies and still = have a single session. We are allowing IPv4 and IPv6 adjacencies to check f= orwarding is working and then use only one session, based on what the opera= tor prioritizes the Address family usage. It is very similar to the usecase= of multiple parallel links, between the same set of devices example as giv= en in RFC 5036. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) wrote: 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 woul= d continue over the single ldp/tcp session for IPV4 and IPV6. Having IPV4 and IPV6 specific hello adjacencies over a link would only deci= de 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 ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 3:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we want co= mplete separation. Ofcourse the assumption is we will have all adjacencies = using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) wrote: That means in mobility backhauls if we are running 10K adjacencies today, t= his draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante= ; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using different= instances of LDP itself or something in between, in which case we can use = different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard wrote: I understand the road LDP has gone down with regards to using a single session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" wrote: >I second to Mustapha. Further, we had already started LDP capabilities >based approach on various FEC types support over a single LDP session >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a >sound approach and would raise other questions such as which adjacency to >be >used for various mLdp fec types etc (as some of those has mix of ipv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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. >> From eric.gray@ericsson.com Fri Feb 10 11:31: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 2F11021F8826 for ; Fri, 10 Feb 2012 11:31:47 -0800 (PST) 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 GDAgm5JhS7J4 for ; Fri, 10 Feb 2012 11:31:45 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B232F21F8796 for ; Fri, 10 Feb 2012 11:31:45 -0800 (PST) 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 q1AJO6B9007674 for ; Fri, 10 Feb 2012 13:24:10 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 10 Feb 2012 14:24:01 -0500 From: Eric Gray To: "mpls@ietf.org" Date: Fri, 10 Feb 2012 14:23:58 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlK+tTB8Rpz30uR5qb6kAxi4wnbAAEURGAALr2BVA= Message-ID: 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: [mpls] FW: 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, 10 Feb 2012 19:31:47 -0000 Forwarded in plain text... ________________________________ From: Kishore Tiruveedhula [mailto:kishoret@juniper.net] Sent: Monday, February 06, 2012 9:29 PM To: Vishwas Manral; Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 How about defining new IPv6 capability Parameter TLV, which can be sent in = the Init message, instead of maintaining two separate Ipv4 and Ipv6 adjacen= cies for single link? Thanks, Kishore From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vis= hwas Manral Sent: Monday, February 06, 2012 7:03 PM To: Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Good points Pranjal. The idea is simple, the current specs allow multiple adjacencies and still = have a single session. We are allowing IPv4 and IPv6 adjacencies to check f= orwarding is working and then use only one session, based on what the opera= tor prioritizes the Address family usage. It is very similar to the usecase= of multiple parallel links, between the same set of devices example as giv= en in RFC 5036. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) wrote: 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 woul= d continue over the single ldp/tcp session for IPV4 and IPV6. Having IPV4 and IPV6 specific hello adjacencies over a link would only deci= de 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 ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 3:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we want co= mplete separation. Ofcourse the assumption is we will have all adjacencies = using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) wrote: That means in mobility backhauls if we are running 10K adjacencies today, t= his draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante= ; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using different= instances of LDP itself or something in between, in which case we can use = different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard wrote: I understand the road LDP has gone down with regards to using a single session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" wrote: >I second to Mustapha. Further, we had already started LDP capabilities >based approach on various FEC types support over a single LDP session >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a >sound approach and would raise other questions such as which adjacency to >be >used for various mLdp fec types etc (as some of those has mix of ipv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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. >> From eric.gray@ericsson.com Fri Feb 10 11:31: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 3474C21F8796 for ; Fri, 10 Feb 2012 11:31:48 -0800 (PST) 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=[AWL=0.000, 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 Qe68tPq+zdA0 for ; Fri, 10 Feb 2012 11:31:46 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2B521F881A for ; Fri, 10 Feb 2012 11:31:45 -0800 (PST) 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 q1AJO2UV007653 for ; Fri, 10 Feb 2012 13:24:08 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 10 Feb 2012 14:24:02 -0500 From: Eric Gray To: "mpls@ietf.org" Date: Fri, 10 Feb 2012 14:23:58 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlK+tTB8Rpz30uR5qb6kAxi4wnbAAEURGAAAFr0fAAuY+SUA== Message-ID: 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: [mpls] FW: 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, 10 Feb 2012 19:31:48 -0000 Forwarded in plain text... ________________________________ From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] Sent: Monday, February 06, 2012 9:51 PM To: Kishore Tiruveedhula; Vishwas Manral Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Yes, that's what I suggested. However it won't solve the concerns raised by= Shane and Phil since IPV4 + IPV4 tunnels would fate share over single ldp = session. The solution to that can be separation of lsr-ids for IPV4 and IPV= 6 sessions between same peers. Thanks, Pranjal ________________________________ From: Kishore Tiruveedhula [mailto:kishoret@juniper.net] Sent: Monday, February 06, 2012 6:29 PM To: Vishwas Manral; Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 How about defining new IPv6 capability Parameter TLV, which can be sent in = the Init message, instead of maintaining two separate Ipv4 and Ipv6 adjacen= cies for single link? Thanks, Kishore From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vis= hwas Manral Sent: Monday, February 06, 2012 7:03 PM To: Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Good points Pranjal. The idea is simple, the current specs allow multiple adjacencies and still = have a single session. We are allowing IPv4 and IPv6 adjacencies to check f= orwarding is working and then use only one session, based on what the opera= tor prioritizes the Address family usage. It is very similar to the usecase= of multiple parallel links, between the same set of devices example as giv= en in RFC 5036. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) wrote: 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 woul= d continue over the single ldp/tcp session for IPV4 and IPV6. Having IPV4 and IPV6 specific hello adjacencies over a link would only deci= de 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 ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 3:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we want co= mplete separation. Ofcourse the assumption is we will have all adjacencies = using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) wrote: That means in mobility backhauls if we are running 10K adjacencies today, t= his draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante= ; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using different= instances of LDP itself or something in between, in which case we can use = different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard wrote: I understand the road LDP has gone down with regards to using a single session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" wrote: >I second to Mustapha. Further, we had already started LDP capabilities >based approach on various FEC types support over a single LDP session >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a >sound approach and would raise other questions such as which adjacency to >be >used for various mLdp fec types etc (as some of those has mix of ipv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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. >> From eric.gray@ericsson.com Fri Feb 10 11:31: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 5F1AC21F881A for ; Fri, 10 Feb 2012 11:31:48 -0800 (PST) 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 HC9U3a-kIZH1 for ; Fri, 10 Feb 2012 11:31:46 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3D621F8821 for ; Fri, 10 Feb 2012 11:31:46 -0800 (PST) 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 q1AJO2US007653 for ; Fri, 10 Feb 2012 13:24:07 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 10 Feb 2012 14:23:59 -0500 From: Eric Gray To: "mpls@ietf.org" Date: Fri, 10 Feb 2012 14:23:56 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlTWdxSHEMtMhvSFeoK0YJ93e0jgAe1UPQAJgqzhA= Message-ID: 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: [mpls] FW: 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, 10 Feb 2012 19:31:48 -0000 Forwarded in plain text... ________________________________ From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] Sent: Tuesday, February 07, 2012 1:49 PM To: Vishwas Manral Cc: Kishore Tiruveedhula; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Viswas, If we use multiple lsr-ids then there would be two separat= e hello adjacencies anyway over a single interface so that situation won't= arise. It would still be 20K adj + sessions if we want fate separation of = ipv4 and ipv6 but is much cleaner then having multiple adjacencies on a link with same peer lsr. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 8:03 PM To: Dutta, Pranjal K (Pranjal) Cc: Kishore Tiruveedhula; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Pranjal, They would definitely share fate if we used one session. However if we used just one adjacency, we would loose a functionality of He= llo's that of verifying peer connectivity. Do you think it is not critical = in such a case? Thanks, Vishwas On Mon, Feb 6, 2012 at 6:50 PM, Dutta, Pranjal K (Pranjal) wrote: Yes, that's what I suggested. However it won't solve the concerns raised by= Shane and Phil since IPV4 + IPV4 tunnels would fate share over single ldp = session. The solution to that can be separation of lsr-ids for IPV4 and IPV= 6 sessions between same peers. Thanks, Pranjal ________________________________ From: Kishore Tiruveedhula [mailto:kishoret@juniper.net] Sent: Monday, February 06, 2012 6:29 PM To: Vishwas Manral; Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 How about defining new IPv6 capability Parameter TLV, which can be sent in = the Init message, instead of maintaining two separate Ipv4 and Ipv6 adjacen= cies for single link? Thanks, Kishore From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vis= hwas Manral Sent: Monday, February 06, 2012 7:03 PM To: Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Good points Pranjal. The idea is simple, the current specs allow multiple adjacencies and still = have a single session. We are allowing IPv4 and IPv6 adjacencies to check f= orwarding is working and then use only one session, based on what the opera= tor prioritizes the Address family usage. It is very similar to the usecase= of multiple parallel links, between the same set of devices example as giv= en in RFC 5036. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) wrote: 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 woul= d continue over the single ldp/tcp session for IPV4 and IPV6. Having IPV4 and IPV6 specific hello adjacencies over a link would only deci= de 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 ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 3:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we want co= mplete separation. Ofcourse the assumption is we will have all adjacencies = using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) wrote: That means in mobility backhauls if we are running 10K adjacencies today, t= his draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante= ; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using different= instances of LDP itself or something in between, in which case we can use = different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we can curre= ntly support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard wrote: I understand the road LDP has gone down with regards to using a single session/adjacency to advertise multiple families of FECs, similar to BGP. Like I said, many providers these days have taken steps to separate their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational folks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two different sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilities for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" wrote: >I second to Mustapha. Further, we had already started LDP capabilities >based approach on various FEC types support over a single LDP session >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a >sound approach and would raise other questions such as which adjacency to >be >used for various mLdp fec types etc (as some of those has mix of ipv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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. >> From eric.gray@ericsson.com Fri Feb 10 11:31: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 7FF4321F8823 for ; Fri, 10 Feb 2012 11:31:50 -0800 (PST) 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=[AWL=0.000, 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 hn437p+Rkpwm for ; Fri, 10 Feb 2012 11:31:48 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC3B21F8824 for ; Fri, 10 Feb 2012 11:31:46 -0800 (PST) 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 q1AJO2UX007653 for ; Fri, 10 Feb 2012 13:24:08 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 10 Feb 2012 14:24:03 -0500 From: Eric Gray To: "mpls@ietf.org" Date: Fri, 10 Feb 2012 14:24:00 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlK+FRTKfoWnKcSjm2S9uK5BvsqQACTSMLALzsx0A= Message-ID: 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: [mpls] FW: 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, 10 Feb 2012 19:31:50 -0000 Forwarded in plain text... ________________________________ From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-lucen= t.com] Sent: Monday, February 06, 2012 8:09 PM To: 'vishwas.ietf@gmail.com'; Dutta, Pranjal K (Pranjal) Cc: 'bedard.phil@gmail.com'; 'shane@castlepoint.net'; 'mpls@ietf.org' Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 There is actually a fundamental difference between the parallel links in RF= C 5036 and this proposal. The tie introduced between any of the Hello adjac= encies and the FEC type advertised. In LDP so far this is controlled by per= -peer prefix policies and LDP capability. If the intent is to provide some level of control plane separation, as expl= ained by Shane and Phil, then we would need separate Hello adjacencies and = separate LDP sessions and let users decide what FEC types they want to use = for each. There is no point of creating a hybrid scheme which doubles the n= umber of adjacencies and changes the LDP state machine for no apparent gain= . Mustapha. Sent from my Blackberry! ________________________________ From: Vishwas Manral To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard ; Aissaoui, Mustapha (Mustapha); Sha= ne Amante ; mpls@ietf.org Sent: Mon Feb 06 18:03:09 2012 Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Good points Pranjal. The idea is simple, the current specs allow multiple adjacencies and still = have a single session. We are allowing IPv4 and IPv6 adjacencies to check f= orwarding is working and then use only one session, based on what the opera= tor prioritizes the Address family usage. It is very similar to the usecase= of multiple parallel links, between the same set of devices example as giv= en in RFC 5036. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) wrote: 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 shar= ing would continue over the single ldp/tcp session for IPV4 and IPV6. Having IPV4 and IPV6 specific hello adjacencies over a link would o= nly 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 ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 3:50 PM To: Dutta, Pranjal K (Pranjal) Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; mpls@= ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 That's correct Pranjal. The other option is to have 20k adjacencies and 20k sessions, if we= want complete separation. Ofcourse the assumption is we will have all adja= cencies using both IPv4 and IPv6. Thanks, Vishwas On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) wrote: That means in mobility backhauls if we are running 10K adjacencies = today, this draft imposes us to run 20K adjacencies in case of IPV6. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 06, 2012 1:12 PM To: Phil Bedard Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shan= e Amante; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Phil, You are right. If we want minimal fate-sharing, we could be using d= ifferent instances of LDP itself or something in between, in which case we = can use different LSR id/ MT extension etc. The draft talks about the case based on current RFC5036, where we c= an currently support multiple hello adjacencies and a single LDP session. The draft also in section 7, mentions the use of LDP capability. Thanks, Vishwas On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard wrote: I understand the road LDP has gone down with regards to using a sin= gle session/adjacency to advertise multiple families of FECs, similar t= o BGP. Like I said, many providers these days have taken steps to separate= their IPv6 and IPv4 control planes, usually for shared-fate concerns with software defects and to just keep things simpler for operational fo= lks to deal with (which is somewhat debatable). Mustapha mentioned BGP but the fact is providers today use two diff= erent sessions to adveritse v4 vs. v6 NLRI, regardless of the capabilitie= s for either to advertise both NLRI. Phil On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)" wrote: >I second to Mustapha. Further, we had already started LDP capabili= ties >based approach on various FEC types support over a single LDP sess= ion >(e.g >mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is= not a >sound approach and would raise other questions such as which adjac= ency to >be >used for various mLdp fec types etc (as some of those has mix of i= pv4 + >ipv6) etc. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beha= lf Of >Aissaoui, Mustapha (Mustapha) >Sent: Monday, February 06, 2012 12: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 tupl= e >{LSR-id, label-space-id}. If two LSR nodes using the same LSR-id w= ant to >advertise two different label spaces, then they must use two diffe= rent >Hello adjacencies and LDP sessions for that. Also, if an implement= ation >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 F= EC >which are carried. For example, the same LDP Hello Adjacency and L= DP >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 I= Pv4 on >an IPv4 session between two LSRs, then we should consider extendi= ng RFC >5036 to allow for two different LSR-id values sharing the same glo= bal >label space. This way, we can have separate Hello adjacency and LD= P >session and it is up to the user to assign which FEC type is allow= ed on >which LDP session. This is a new work item but in my view much cle= aner >and backward compatible with RFC 5036 than to try to tie the addre= ss >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 inpu= t 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 e= ach >address family. (If my impression is incorrect I apologize). > >I actually *do* want to have separate LDP Hello and Session adjace= ncies: >one per address family, at least at this point in time. I'm concer= ned >about [operational] issues that may develop in, for example, v6 af= fecting >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 im= proving >the robustness of IPv6 ND to DoS attacks. There are potentially ot= her >areas where IPv6 will be hardened, as well. The bottom-line is I d= o not >want problems in v6 to affect exchange of FEC's + labels for v4, o= r >vice-versa. Also, FWIW, there has already been a precedent here wr= t BGP >where there it maintains separate neighbors/sessions for each addr= ess >family, so why aren't we doing the same thing for LDP? > >Ultimately, having separate sessions over-the-wire is much more in= tuitive >to operators in lots of cases where they may expect that a configu= ration >change or bugs they /think/ are only going to affect one address f= amily, >really do only affect one address family. Besides, LDP Hello & Ses= sions >timers, when set to default, are extremely relaxed (order of sever= al >seconds), so the burden on implementations to maintain separate se= ssions >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 shar= e 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 m= ailing >>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 referri= ng 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 sh= ould >>explicitly refer to /128 for IPv6. >> >> >> 2. Section 3 - LSP Mapping; last Paragraph: >> " >> Additionally, it is desirable that a packet is forwarded to an L= SP of >>an egress router, only if LSP's address-family (e.g. LSPv4 or LSP= v6) >>matches with that of the LDP hello adjacency on the next-hop inte= rface. >> " >> 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 stat= ement >>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 theref= ore >> updates that sentence to the following: "For a given address f= amily >> over which a Hello is sent, and a given label space, an LSR MU= ST >> advertise the same transport address." This rightly enables th= e 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 th= at >>advertise the same label space. In fact the intent as explained i= n the >>second sentence of that same paragraph was to make sure that if t= wo LSRs >>are establishing multiple Hello adjacencies that they play the sa= me >>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 wor= ks 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 messa= ges >>over a dual-stack interface since there could be both IPv4 and IP= v6 LSRs >>on the same subnet. However, this does not justify the need to ma= intain >>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 interfa= ce, >>whichever came up first. Over a P2P interface, it is up to the us= er 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 IPv= 4 >> 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 me= ssage >>is processed. >> >> >> 6. Section 6.1 - Transport connection establishment " >> 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a n= ew >> LDP session with a remote LSR, if it has both IPv4 and IP= v6 >> hello adjacencies for the same LDP Identifier (over a dua= l- >> stack interface, or two or more single-stack IPv4 and IPv= 6 >> interfaces). This applies to the section 2.5.2 of RFC5036= . >> >> 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a n= ew >> 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 adjac= ency 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 p= eer >> 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 bind= ings >>should depend on the existence of an IPv6 Hello adjacency. This i= s 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 multica= st LDP >>(mLDP) FECs. >> >> >> 8. Section 7 - Label Distribution; Fourth paragraph: >> " >> Additionally, to ensure backward compatibility (and interoperabi= lity >> with IPv4-only LDP implementations), this document specifies tha= t >> - 1. An LSR MUST NOT send a label mapping message with a FEC TLV >>containing FEC Elements of different address-family. In other wor= ds, a >>FEC TLV in the label mapping message MUST contain the FEC Element= s >>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 diff= erent >>address-family. In other words, an Address List TLV in the Addres= s (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 sufficien= t. >>Although implementations don't mix and match FEC elements but the= y 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 r= eceived >>from two different peers is not a new issue. It needed to be hand= led in >>existing IPv4 based LDP implementations. Maybe the authors can sp= ecify >>why duplicate link local addresses is any different. >> >> >> 10. Section 9 - LDP TTL Security >> " >> This document also specifies that the LDP/TCP transport connecti= on >> over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Secu= rity >> Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LD= P >> session peering established between the adjacent LSRs using Ba= sic >> Discovery, by default. >> " >> MA> GTSM must be optional as explained in RFC 5082. This draft i= s not >>defining a new protocol and as such it should remain optional as = in RFC >>5036. >> From masahiko.mizutani.ew@hitachi.com Fri Feb 10 21:08: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 7EB2E11E8080 for ; Fri, 10 Feb 2012 21:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.523 X-Spam-Level: ** X-Spam-Status: No, score=2.523 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] 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 wt4HrfSjg-Wp for ; Fri, 10 Feb 2012 21:08:49 -0800 (PST) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1C11E807F for ; Fri, 10 Feb 2012 21:08:48 -0800 (PST) Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id D5B8F37C84; Sat, 11 Feb 2012 14:08:47 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id q1B58lLJ005192; Sat, 11 Feb 2012 14:08:47 +0900 Received: from vshuts2.hitachi.co.jp (vshuts2.hitachi.co.jp [10.201.6.71]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q1B58k4j003302; Sat, 11 Feb 2012 14:08:47 +0900 X-AuditID: b753bd60-9aa63ba00000359c-f8-4f35f7db9a1d Received: from gmaxml17.clb.hitachi.co.jp (unknown [158.213.157.137]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id BD3038B031C; Sat, 11 Feb 2012 14:08:43 +0900 (JST) Received: from [127.0.0.1] by gmaxml17.clb.hitachi.co.jp (Switch-3.1.9/Switch-3.1.9) id 41B5187CR0000B1D8; Sat, 11 Feb 2012 14:08:43 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: , From: Date: Sat, 11 Feb 2012 14:08:33 +0900 References: <4F327811.1000700@pi.nu> Priority: normal Importance: normal X400-Content-Identifier: X4F35F7CE00000M X400-MTS-Identifier: [/C=JP/ADMD=GMGROUP/PRMD=GMGROUP/;mta18120211140830IFD] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] =?iso-2022-jp?b?UG9sbCBvbiBkcmFmdC1rb2lrZS1tcGxzLXRwLXRl?= =?iso-2022-jp?b?bXBvcmFsLWhpdGxlc3MtcHNt?= 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, 11 Feb 2012 05:08:49 -0000 Yes/Support. Regards, Masahiko >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 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From mtinka@globaltransit.net Sat Feb 11 01:31: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 29BE721F8532 for ; Sat, 11 Feb 2012 01:31:07 -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 nTjy-hHss2xo for ; Sat, 11 Feb 2012 01:31:06 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.223.132.216]) by ietfa.amsl.com (Postfix) with ESMTP id F1B5921F8597 for ; Sat, 11 Feb 2012 01:31:03 -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 1Rw9HY-0008Hm-Vl; Sat, 11 Feb 2012 17:30:12 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Sat, 11 Feb 2012 17:30:00 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4613894.mTEJD9qrD9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201202111730.03501.mtinka@globaltransit.net> Cc: "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, 11 Feb 2012 09:31:07 -0000 --nextPart4613894.mTEJD9qrD9 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday, February 07, 2012 04:44:58 AM Phil Bedard wrote: > I understand the road LDP has gone down with regards to > using a single session/adjacency to advertise multiple > families of FECs, similar to BGP. Like I said, many > providers these days have taken steps to separate their > IPv6 and IPv4 control planes, usually for shared-fate > concerns with software defects and to just keep things > simpler for operational folks to deal with (which is > somewhat debatable). As an operator, I have to agree with Phil as well. Operators will expect that LDPv4 and LDPv6 will likely be=20 different adjacencies, with independent FEC for each address=20 family, even though the capabilities being advertised by LDP=20 may be the same, but only activated based on whether those=20 capabilities are in operation for that particular address=20 family or not. At any rate, fate sharing would be undesireable for=20 operators. Moreover, I'd prefer that if operators have=20 choice in how LDP would operate, independence of adjacencies=20 and FEC's be the default, and a combination be optional. > Mustapha mentioned BGP but the fact is providers today > use two different sessions to adveritse v4 vs. v6 NLRI, > regardless of the capabilities for either to advertise > both NLRI. This is very true. In dual-stack systems, we (and a number of other operators)=20 will have separate but similar deployments between IPv4 and=20 IPv6 protocols. IS-IS is just about the only exception, but=20 while the protocol integrates support for both IPv4 and=20 IPv6, we still consider the operation of adjacencies=20 separate on the wire. Mark. --nextPart4613894.mTEJD9qrD9 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) iQIcBAABAgAGBQJPNjUbAAoJEGcZuYTeKm+Gh/EP/1ItyhyBW1S1FB9YoqGvimWC 4WuvkeIqQP2PvSDd/UwVMQoTd3unksPwe78DxK1LczneJ3uVCeN0KnMEdaLmyZrD NKp2loPTdfhxC/S+lewjPZlfda1rSyOhIDPJuCKBFA4Bz2g2W/ANgNW+vE9qfw67 2+8hnaWuLqGhqNnkaM0wgCNGpLOYT4sMG0WLU5dm8QmprdZOEi3s4RzWNkVt62gY 7uHLf6/RgQYAWsvDwiAt9IiGm5SGKds4dcpEUjxq5QuL1y2xHDpxC4GhL0sS+ucx E64Y+qzQP/ce6vD3a6TFVqtkZoh+yes7/ThwAGtGO/tzirfMxWQK6Y4HjTdBOrp2 aFZC8mF47KWIJ3FQEEclofJdpiFi81SqkSjVB3q+/fnBy+rv7InTKjUAgmqMat90 OFUPpIDM4JOOmuwAkDy2cuwVNlrv90m/4ps8AEaQxRKftoqHvKZbw/EPNnKUaHHK VjUP9SZC0aQF/oR/ltOmYtcPeEq2qOon3rh7TYh256SUZVrbqx+/D3t7X46IDrrx ODNxECzfquadDEOzy1AH5f7qjm71lHNCmK8CrBYIWXbDuDEDLtez5n/3jDYAoRjt hlGPnteBT2O02u3xi0vevZDaS68BcQssVNJ3Bj1Ksfb0KhICoixpC2OPqsYcKHUs cUPVQE4I1i1YmY3+1hDk =+Oyk -----END PGP SIGNATURE----- --nextPart4613894.mTEJD9qrD9-- From yaacov.weingarten@nsn.com Sun Feb 12 03:52: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 BA63D21F860B for ; Sun, 12 Feb 2012 03:52:38 -0800 (PST) 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=[AWL=0.000, 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 fZvF8dQJDlf6 for ; Sun, 12 Feb 2012 03:52:38 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E81A921F843E for ; Sun, 12 Feb 2012 03:52:37 -0800 (PST) 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 q1CBqZbG005318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 12 Feb 2012 12:52:36 +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 q1CBqZjb002127 for ; Sun, 12 Feb 2012 12:52:35 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Feb 2012 12:52:35 +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, 12 Feb 2012 12:52:27 +0100 Message-ID: In-Reply-To: <4F327811.1000700@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm Thread-Index: AczmZVYjbkWdYeFWSmSh0XSi/MmoUQDF2QCw References: <4F327811.1000700@pi.nu> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 12 Feb 2012 11:52:35.0331 (UTC) FILETIME=[CF7EC530:01CCE97C] 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: 1111 X-purgate-ID: 151667::1329047556-00007EDF-8263B387/0-0/0-0 Subject: Re: [mpls] 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: Sun, 12 Feb 2012 11:52:38 -0000 Yes/Support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Wednesday, February 08, 2012 3:27 PM 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 Subject: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm 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 --=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 From nurit.sprecher@nsn.com Sun Feb 12 04:33: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 DF65221F8682 for ; Sun, 12 Feb 2012 04:33:18 -0800 (PST) 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.068, 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 ScXEe9HB-Qa3 for ; Sun, 12 Feb 2012 04:33:18 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2A221F8670 for ; Sun, 12 Feb 2012 04:33:17 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1CCXHKY019509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 12 Feb 2012 13:33:17 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1CCXGR4016185 for ; Sun, 12 Feb 2012 13:33:17 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Feb 2012 13:33:16 +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, 12 Feb 2012 13:33:11 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640550DA9A@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm Thread-Index: AczmZVYjbkWdYeFWSmSh0XSi/MmoUQDF2QCwAAFuG+A= References: <4F327811.1000700@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 12 Feb 2012 12:33:16.0719 (UTC) FILETIME=[7EAD03F0:01CCE982] 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: 1238 X-purgate-ID: 151667::1329049997-00007EDF-6C654090/0-0/0-0 Subject: Re: [mpls] 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: Sun, 12 Feb 2012 12:33:19 -0000 Yes/support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Wednesday, February 08, 2012 3:27 PM 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 Subject: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm 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 --=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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ryoo@etri.re.kr Sun Feb 12 16:27: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 28BB721F8721 for ; Sun, 12 Feb 2012 16:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.849 X-Spam-Level: X-Spam-Status: No, score=-98.849 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_IMAGE_ONLY_28=1.561, 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 LS++mDRSFDqp for ; Sun, 12 Feb 2012 16:27:10 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id 08A2E21F871E for ; Sun, 12 Feb 2012 16:27:09 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Mon, 13 Feb 2012 09:27:08 +0900 Priority: normal X-ReadCheckName: mpls%40ietf.org Thread-Topic: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm X-ReadCheckMessageID: <6e227267-d62a-4be4-b37f-d5e32214a97b@etri.re.kr> thread-index: Aczp5jhC68wozYJFR5yreswb4Zflpw== Content-Transfer-Encoding: 7bit From: "Ryoo, Jeong-dong" To: "Loa Andersson" , , "MPLS-TP ad hoc team" , , "Ross Callon" , "George Swallow" , "Adrian Farrel" Date: Mon, 13 Feb 2012 09:27:08 +0900 Comment: ??, ???, Message-ID: <7036CEA5DC3340CE8959AB3466180E8E@etri.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F58_01CCEA31.A82EFAD0" 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: 13 Feb 2012 00:27:08.0489 (UTC) FILETIME=[38667390:01CCE9E6] Subject: Re: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm 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: Mon, 13 Feb 2012 00:27:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0F58_01CCEA31.A82EFAD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_0F58_01CCEA31.A82EFAD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiIGlkPW1zZ2Jv ZHk+DQo8RElWPlN1cHBvcnQuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5KZW9uZy1k b25nIFJ5b288L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gIkxvYSBBbmRlcnNz b24iICZsdDtsb2FAcGkubnUmZ3Q7PEJSPjxCPkZyb20gRGF0ZTo8L0I+IDIwMTItMDItMDggUE0g MTA6MjY6NDE8QlI+PEI+VG86PC9CPiAibXBsc0BpZXRmLm9yZyIgJmx0O21wbHNAaWV0Zi5vcmcm Z3Q7LCAiTVBMUy1UUCBhZCBob2MgdGVhbSIgJmx0O2FobXBscy10cEBsaXN0cy5pdHUuaW50Jmd0 OywgImRyYWZ0LWtvaWtlLW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1wc21AdG9vbHMuaWV0Zi5v cmciICZsdDtkcmFmdC1rb2lrZS1tcGxzLXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtQHRvb2xzLmll dGYub3JnJmd0OywgIlJvc3MgQ2FsbG9uIiAmbHQ7cmNhbGxvbkBqdW5pcGVyLm5ldCZndDssICJH ZW9yZ2UgU3dhbGxvdyIgJmx0O3N3YWxsb3dAY2lzY28uY29tJmd0OywgIkFkcmlhbiBGYXJyZWwi ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OzxCUj48Qj5DYzo8L0I+IDxCUj48Qj5TdWJqZWN0 OjwvQj4gW21wbHNdIFBvbGwgb24gZHJhZnQta29pa2UtbXBscy10cC10ZW1wb3JhbC1oaXRsZXNz LXBzbTxCUj48QlI+DQo8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQg LS0+PEJSPg0KPFA+PEZPTlQgc2l6ZT0yPldvcmtpbmcgR3JvdXAsPEJSPjxCUj50aGlzIGlzIHRv IHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCB0byBzZWUgaWYgdGhlcmUgaXMgc3VwcG9ydCB0byBtYWtl PEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQta29pa2UtbXBscy10cC10ZW1wb3JhbC1o aXRsZXNzLXBzbS0wNDxCUj48QlI+bXBscyB3b3JraW5nIGdyb3VwIGRyYWZ0cy48QlI+PEJSPlBs ZWFzZWQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGlu ZyBsaXN0PEJSPihtcGxzQGlldGYub3JnKS48QlI+PEJSPlRoaXMgcG9sbCBlbmRzIEZlYnJ1YXJ5 IDIyLCAyMDEyITxCUj48QlI+TG9hPEJSPmZvciB0aGUgbXBscyB3ZyBjaGFpcnM8QlI+PEJSPjxC Uj4tLTxCUj48QlI+PEJSPkxvYSBBbmRlcnNzb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPEJSPlNyIFN0cmF0ZWd5IGFuZCBT dGFuZGFyZHMgTWFuYWdlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb2FAcGkubnU8QlI+RXJpY3Nzb24gSW5jJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBob25lOiArNDYgMTAgNzE3IDUyIDEzPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArNDYgNzY3IDcyIDky IDEzPEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJS Pm1wbHMgbWFpbGluZyBsaXN0PEJSPm1wbHNAaWV0Zi5vcmc8QlI+PEEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvQT48QlI+PC9GT05UPjwvUD48L0RJ Vj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAg c3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFp bD1tcGxzQGlldGYub3JnJm5hbWU9bXBscyU0MGlldGYub3JnJmZyb21lbWFpbD1yeW9vQGV0cmku cmUua3ImbWVzc2FnZWlkPSUzQzZlMjI3MjY3LWQ2MmEtNGJlNC1iMzdmLWQ1ZTMyMjE0YTk3YkBl dHJpLnJlLmtyJTNFIj4= ------=_NextPart_000_0F58_01CCEA31.A82EFAD0-- From c-sai@bx.jp.nec.com Sun Feb 12 16:53: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 66DE821F8627 for ; Sun, 12 Feb 2012 16:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 V-KlUs3ACcQK for ; Sun, 12 Feb 2012 16:53:22 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id B64AB21F86B3 for ; Sun, 12 Feb 2012 16:53:21 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1D0rK2F004402 for ; Mon, 13 Feb 2012 09:53:20 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q1D0rKF22849 for mpls@ietf.org; Mon, 13 Feb 2012 09:53:20 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1D0r5Y4020919 for ; Mon, 13 Feb 2012 09:53:20 +0900 (JST) Received: from yonosuke.jp.nec.com ([10.26.220.15] [10.26.220.15]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-895869; Mon, 13 Feb 2012 09:52:58 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTP; Mon, 13 Feb 2012 09:52:57 +0900 From: "Zhenlong Cui" To: References: <4F327811.1000700@pi.nu> Date: Mon, 13 Feb 2012 09:52:57 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4F327811.1000700@pi.nu> Thread-Index: AczmZVDin3rL32rUQyK0Tfpf6nZcnADg9zAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [mpls] 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: Mon, 13 Feb 2012 00:53:22 -0000 Yes/support. I would like to raise some comments regarding section 6. I think performance monitoring is different from the survivability analysis, as it has a certain time-dependent behavior. Therefore, I think the on-demand single-level segment monitoring must "timely coordinate" with the other levels that include the pro-active end-to-end monitoring. I suggest adding some description to section 6 along these lines: In order to increase the accuracy of performance monitoring, on-demand multi-level performance monitoring must have the ability to execute at all levels at the same time. Best Regards, zhenlong > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, February 08, 2012 10:27 PM > 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 > Subject: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm > > 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Wed Feb 15 00:02: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 1538221E806F; Wed, 15 Feb 2012 00:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 w427-Go3Lx7K; Wed, 15 Feb 2012 00:02:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5278A21E800C; Wed, 15 Feb 2012 00:02:11 -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: 3.64p2 Message-ID: <20120215080211.13872.91960.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2012 00:02:11 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ring-protection-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: Wed, 15 Feb 2012 08:02:12 -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 : Applicability of MPLS-TP Linear Protection for Ring Topo= logies Author(s) : Yaacov Weingarten Stewart Bryant Nurit Sprecher Danielle Ceccarelli Diego Caviglia Francesco Fondelli Marco Corsi Bo Wu Xuehui Dai Filename : draft-ietf-mpls-tp-ring-protection-01.txt Pages : 28 Date : 2012-02-15 This document presents an applicability statement to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on multiple layers. The MPLS-TP Requirements document specifies specific criteria for justification of dedicated protection mechanism for particular topologies, including optimizing the number of OAM entities needed, minimizing the number of labels for protection paths, minimizing the number of recovery elements in the network, and minimizing the number of control and management transactions necessary. The document proposes a methodology for ring protection based on existing MPLS-TP survivability mechanisms, specifically those defined in MPLS-TP Linear Protection, without the need for specification of new constructs or protocols. 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 as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-01.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-ring-protection-01.txt From yaacov.weingarten@nsn.com Wed Feb 15 00:05: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 5269121F8573 for ; Wed, 15 Feb 2012 00:05:12 -0800 (PST) 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=[AWL=0.000, 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 w6YxiOzVlmLW for ; Wed, 15 Feb 2012 00:05:11 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB0921F854B for ; Wed, 15 Feb 2012 00:05:10 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1F854qu025703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Feb 2012 09:05:04 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1F85313025403; Wed, 15 Feb 2012 09:05:03 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 09:05:00 +0100 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: Wed, 15 Feb 2012 09:04:58 +0100 Message-ID: In-Reply-To: <20120215080211.13872.48387.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-mpls-tp-ring-protection-01.txt Thread-Index: AczruCJtmPVUGlr8QyepHRlbmALP7QAABM8Q References: <20120215080211.13872.48387.idtracker@ietfa.amsl.com> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 15 Feb 2012 08:05:00.0663 (UTC) FILETIME=[83EB0870:01CCEBB8] 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: 3502 X-purgate-ID: 151667::1329293104-00007EDF-D0C8F3FF/0-0/0-0 Cc: wu.bo@zte.com.cn, dai.xuehui@zte.com.cn, marco.corsi@altran.it, francesco.fondelli@ericsson.com Subject: Re: [mpls] New Version Notification for draft-ietf-mpls-tp-ring-protection-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: Wed, 15 Feb 2012 08:05:12 -0000 SGkgYWxsLA0KDQpUaGlzIG5ldyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgY29tbWVudHMgdGhhdCB3 ZXJlIHN1Ym1pdHRlZCBkdXJpbmcgdGhlIHBvbGwgZm9yIGFjY2VwdGFuY2UgYXMgYSBXRyBkcmFm dC4NCg0KUGxlYXNlIGxldCB0aGUgYXV0aG9ycyBrbm93IGlmIHRoZXJlIGFyZSBhZGRpdGlvbmFs IHBvaW50cyB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQuDQoNCkJSLA0KWWFhY292IFdlaW5nYXJ0 ZW4NCk5va2lhIFNpZW1lbnMgTmV0d29ya3MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGV4dCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxMiAxMDowMiBB TQ0KVG86IFdlaW5nYXJ0ZW4sIFlhYWNvdiAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKQ0KQ2M6IFdl aW5nYXJ0ZW4sIFlhYWNvdiAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgd3UuYm9AenRlLmNvbS5j bjsgZGFpLnh1ZWh1aUB6dGUuY29tLmNuOyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBI YVNoYXJvbik7IGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbTsgbWFyY28uY29yc2lAYWx0cmFu Lml0OyBmcmFuY2VzY28uZm9uZGVsbGlAZXJpY3Nzb24uY29tOyBkYW5pZWxlLmNlY2NhcmVsbGlA ZXJpY3Nzb24uY29tOyBzdGJyeWFudEBjaXNjby5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMS50eHQN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rp b24tMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWWFhY292IFdlaW5n YXJ0ZW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NClJldmlzaW9uOgkgMDENClRpdGxlOgkJ IEFwcGxpY2FiaWxpdHkgb2YgTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiBmb3IgUmluZyBUb3Bv bG9naWVzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wMi0xNQ0KV0cgSUQ6CQkgbXBscw0KTnVtYmVy IG9mIHBhZ2VzOiAyOA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYW4g YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgdG8gYWRkcmVzcyB0aGUNCiAgIHJlcXVpcmVtZW50cyBm b3IgcHJvdGVjdGlvbiBvZiByaW5nIHRvcG9sb2dpZXMgZm9yIE11bHRpLVByb3RvY29sDQogICBM YWJlbCBTd2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIExhYmVsIFN3aXRjaGVk IFBhdGhzDQogICAoTFNQKSBvbiBtdWx0aXBsZSBsYXllcnMuICBUaGUgTVBMUy1UUCBSZXF1aXJl bWVudHMgZG9jdW1lbnQNCiAgIHNwZWNpZmllcyBzcGVjaWZpYyBjcml0ZXJpYSBmb3IganVzdGlm aWNhdGlvbiBvZiBkZWRpY2F0ZWQgcHJvdGVjdGlvbg0KICAgbWVjaGFuaXNtIGZvciBwYXJ0aWN1 bGFyIHRvcG9sb2dpZXMsIGluY2x1ZGluZyBvcHRpbWl6aW5nIHRoZSBudW1iZXINCiAgIG9mIE9B TSBlbnRpdGllcyBuZWVkZWQsIG1pbmltaXppbmcgdGhlIG51bWJlciBvZiBsYWJlbHMgZm9yDQog ICBwcm90ZWN0aW9uIHBhdGhzLCBtaW5pbWl6aW5nIHRoZSBudW1iZXIgb2YgcmVjb3ZlcnkgZWxl bWVudHMgaW4gdGhlDQogICBuZXR3b3JrLCBhbmQgbWluaW1pemluZyB0aGUgbnVtYmVyIG9mIGNv bnRyb2wgYW5kIG1hbmFnZW1lbnQNCiAgIHRyYW5zYWN0aW9ucyBuZWNlc3NhcnkuICBUaGUgZG9j dW1lbnQgcHJvcG9zZXMgYSBtZXRob2RvbG9neSBmb3IgcmluZw0KICAgcHJvdGVjdGlvbiBiYXNl ZCBvbiBleGlzdGluZyBNUExTLVRQIHN1cnZpdmFiaWxpdHkgbWVjaGFuaXNtcywNCiAgIHNwZWNp ZmljYWxseSB0aG9zZSBkZWZpbmVkIGluIE1QTFMtVFAgTGluZWFyIFByb3RlY3Rpb24sIHdpdGhv dXQgdGhlDQogICBuZWVkIGZvciBzcGVjaWZpY2F0aW9uIG9mIG5ldyBjb25zdHJ1Y3RzIG9yIHBy b3RvY29scy4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgYSBqb2ludCBJbnRl cm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlDQogICAoSUVURikgLyBJbnRlcm5hdGlvbmFsIFRl bGVjb21tdW5pY2F0aW9ucyBVbmlvbiBUZWxlY29tbXVuaWNhdGlvbnMNCiAgIFN0YW5kYXJkaXph dGlvbiBTZWN0b3IgKElUVS1UKSBlZmZvcnQgdG8gaW5jbHVkZSBhbiBNUExTIFRyYW5zcG9ydA0K ICAgUHJvZmlsZSB3aXRoaW4gdGhlIElFVEYgTVBMUyBhbmQgUFdFMyBhcmNoaXRlY3R1cmVzIHRv IHN1cHBvcnQgdGhlDQogICBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0aW9uYWxpdGllcyBvZiBhIHBh Y2tldCB0cmFuc3BvcnQgbmV0d29yayBhcw0KICAgZGVmaW5lZCBieSB0aGUgSVRVLVQuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From Manuel.Paul@telekom.de Wed Feb 15 06:18: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 D5D9321F85B9 for ; Wed, 15 Feb 2012 06:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 ACWUcIAJDT+F for ; Wed, 15 Feb 2012 06:18:11 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1F05821F8585 for ; Wed, 15 Feb 2012 06:18:10 -0800 (PST) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 15 Feb 2012 15:17:32 +0100 Received: from HE101452.emea1.cds.t-internal.com ([169.254.2.26]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Wed, 15 Feb 2012 15:17:32 +0100 From: To: , , , , , , Date: Wed, 15 Feb 2012 15:17:31 +0100 Thread-Topic: Poll on draft-koike-mpls-tp-temporal-hitless-psm Thread-Index: AczmZZaHcLwFvxa8TtWug7GIV/E8vAFhtuow Message-ID: <9435EDACD941174099E143BCA2BCD615F91BF94DFC@HE101452.emea1.cds.t-internal.com> References: <4F327811.1000700@pi.nu> In-Reply-To: <4F327811.1000700@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] 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: Wed, 15 Feb 2012 14:18:11 -0000 U3VwcG9ydCAoYXMgYSBjby1hdXRob3IpLg0KDQpUaGFua3MsDQpNYW51ZWwNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBp Lm51XQ0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDEyIDI6MjcgUE0NCj4gVG86 IG1wbHNAaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWtvaWtlLW1wbHMtdHAt dGVtcG9yYWwtDQo+IGhpdGxlc3MtcHNtQHRvb2xzLmlldGYub3JnOyBSb3NzIENhbGxvbjsgR2Vv cmdlIFN3YWxsb3c7IEFkcmlhbiBGYXJyZWwNCj4gU3ViamVjdDogUG9sbCBvbiBkcmFmdC1rb2lr ZS1tcGxzLXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtDQo+DQo+IFdvcmtpbmcgR3JvdXAsDQo+DQo+ IHRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIHRvIHNlZSBpZiB0aGVyZSBpcyBzdXBw b3J0IHRvIG1ha2UNCj4NCj4gICAgIGRyYWZ0LWtvaWtlLW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVz cy1wc20tMDQNCj4NCj4gbXBscyB3b3JraW5nIGdyb3VwIGRyYWZ0cy4NCj4NCj4gUGxlYXNlZCBz ZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QN Cj4gKG1wbHNAaWV0Zi5vcmcpLg0KPg0KPiBUaGlzIHBvbGwgZW5kcyBGZWJydWFyeSAyMiwgMjAx MiENCj4NCj4gTG9hDQo+IGZvciB0aGUgbXBscyB3ZyBjaGFpcnMNCj4NCj4NCj4gLS0NCj4NCj4N Cj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVy c3NvbkBlcmljc3Nvbi5jb20NCj4gU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAg ICAgICAgICAgbG9hQHBpLm51DQo+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAg ICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCg== From agmalis@gmail.com Wed Feb 15 06:52: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 64F7A21F8532 for ; Wed, 15 Feb 2012 06:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WITMvOXvTaoC for ; Wed, 15 Feb 2012 06:52:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D26721F852A for ; Wed, 15 Feb 2012 06:52:44 -0800 (PST) Received: by iagf6 with SMTP id f6so1832965iag.31 for ; Wed, 15 Feb 2012 06:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=4OsOV1qdgXba8RBORG27c3+U2sQK1DxOEudkyfszSNQ=; b=kI0LeaXgSl7QVa99Xrcs2AUgAHcfkyi1tI4T8B8RiIYMHytlw/lU81YIDHes4z12Fh 6CfcSXoFS+4AEEdCxjEC0m+pY59rVIhg4AouObigY5mhhAoX9C8b82e346HyvalaCbTY BfUcYrgXQJI3VfunzTP4gPdIXg5/JvjXr0jg0= Received: by 10.42.145.131 with SMTP id f3mr39810069icv.8.1329317563833; Wed, 15 Feb 2012 06:52:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.171.106 with HTTP; Wed, 15 Feb 2012 06:52:23 -0800 (PST) In-Reply-To: <4F327811.1000700@pi.nu> References: <4F327811.1000700@pi.nu> From: "Andrew G. Malis" Date: Wed, 15 Feb 2012 09:52:23 -0500 Message-ID: To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] 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: Wed, 15 Feb 2012 14:52:48 -0000 Yes/support. Cheers, Andy On Wed, Feb 8, 2012 at 8:26 AM, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > > =A0 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From liu.guoman@zte.com.cn Wed Feb 15 07:19: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 6960021F84FE for ; Wed, 15 Feb 2012 07:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Bx2-CIAUeJeE for ; Wed, 15 Feb 2012 07:19:38 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A588421F872E for ; Wed, 15 Feb 2012 07:19:37 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12280806486374; Wed, 15 Feb 2012 22:51:28 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 25197.806486374; Wed, 15 Feb 2012 23:19:22 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id q1FFJMgU042522 for ; Wed, 15 Feb 2012 23:19:22 +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 q1F9JIR7015551; Wed, 15 Feb 2012 17:19:18 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201202151519.q1FFJMgU042522@mse01.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 From: liu.guoman@zte.com.cn Date: Wed, 15 Feb 2012 17:19:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-15 17:19:19, Serialize complete at 2012-02-15 17:19:19 Content-Type: multipart/alternative; boundary="=_alternative 003336FE482579A5_=" X-MAIL: mse01.zte.com.cn q1FFJMgU042522 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: mpls@ietf.org, marco.corsi@altran.it, francesco.fondelli@ericsson.com Subject: Re: [mpls] New Version Notification for draft-ietf-mpls-tp-ring-protection-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: Wed, 15 Feb 2012 15:19:42 -0000 This is a multipart message in MIME format. --=_alternative 003336FE482579A5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 eWFhY292LGhpDQppIHRoaW5rIGl0IG5vdCBjbGV2ZXIgbWV0aG9kIHRvIGFwcGx5IDErMSBwcm90 ZWN0aW9uIHNvbHV0aW9uIGZvciB0aGUgDQp0cmFmZmljIG9uIHRoZSByaW5nLiBhcyBpIGtub3cs IDUwJSByZXNvdXJjZSBpcyB1c2VkIGZvciB3b3JraW5nIHBhdGgsDQphbmQgYW5vdGhlciA1MCUg cmVzb3VyY2UgaXMgdXNlZCB0byBwcm90ZWN0aW5nIHBhdGgsIGlmIHlvdSBhcHBseSAxKzEgaW4g DQpwMm1wIHN0ZWVyaW5nIHNvbHV0aW9uLCBpIHN1c3BlY3QgdGhlIHJlc291cmNlIG9mIHRoZSBy aW5nIGlzIG5vdCANCmFkZXF1YXRlLg0KYW5kIHVuZGVyIG5vcm1hbCBjb25kaXRpb24sIGFwcGx5 aW5nIDErMSBzb2x1dGlvbiB3aWxsIHdhc3RlIGRvdWJsZSB0aGUgDQpyZXNvdXJjZSBvZiAgdGhl IHJpbmcuDQoNCnNvIGkgdGhpbmsgd2Ugc2hvdWxkIGNvbnRpbnVlIHRvIGNvbnNpZGVyIGEgZ29v ZCBzb2x1dGlvbiBmb3Igc3RlZXJpbmcgDQpwcm90ZWN0aW9uLg0KaXQgaXMgbXkgcGVyc29uYWwg b3BpbmlvbnMsIHRoYW5rIHlvdSENCg0KQi5SLg0KbGl1DQoNCg0KDQoNCg0KDQoNCiJXZWluZ2Fy dGVuLCBZYWFjb3YgKE5TTiAtIElML0hvZCBIYVNoYXJvbikiIDx5YWFjb3Yud2VpbmdhcnRlbkBu c24uY29tPiANCreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0wMi0xNSAxNjow NA0KDQrK1bz+yMsNCjxtcGxzQGlldGYub3JnPg0Ks63LzQ0Kd3UuYm9AenRlLmNvbS5jbiwgZGFp Lnh1ZWh1aUB6dGUuY29tLmNuLCBtYXJjby5jb3JzaUBhbHRyYW4uaXQsIA0KZnJhbmNlc2NvLmZv bmRlbGxpQGVyaWNzc29uLmNvbQ0K1vfM4g0KUmU6IFttcGxzXSBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIA0KZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMS50eHQNCg0K DQoNCg0KDQoNCkhpIGFsbCwNCg0KVGhpcyBuZXcgdmVyc2lvbiBhZGRyZXNzZXMgdGhlIGNvbW1l bnRzIHRoYXQgd2VyZSBzdWJtaXR0ZWQgZHVyaW5nIHRoZSANCnBvbGwgZm9yIGFjY2VwdGFuY2Ug YXMgYSBXRyBkcmFmdC4NCg0KUGxlYXNlIGxldCB0aGUgYXV0aG9ycyBrbm93IGlmIHRoZXJlIGFy ZSBhZGRpdGlvbmFsIHBvaW50cyB0aGF0IHNob3VsZCBiZSANCmFkZHJlc3NlZC4NCg0KQlIsDQpZ YWFjb3YgV2VpbmdhcnRlbg0KTm9raWEgU2llbWVucyBOZXR3b3Jrcw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1 LCAyMDEyIDEwOjAyIEFNDQpUbzogV2VpbmdhcnRlbiwgWWFhY292IChOU04gLSBJTC9Ib2QgSGFT aGFyb24pDQpDYzogV2VpbmdhcnRlbiwgWWFhY292IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyB3 dS5ib0B6dGUuY29tLmNuOyANCmRhaS54dWVodWlAenRlLmNvbS5jbjsgU3ByZWNoZXIsIE51cml0 IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyANCmRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbTsg bWFyY28uY29yc2lAYWx0cmFuLml0OyANCmZyYW5jZXNjby5mb25kZWxsaUBlcmljc3Nvbi5jb207 IGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb207IA0Kc3RicnlhbnRAY2lzY28uY29tDQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQtaWV0Zi1tcGxzLXRw LXJpbmctcHJvdGVjdGlvbi0wMS50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWll dGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDEudHh0IGhhcyBiZWVuIA0Kc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBZYWFjb3YgV2VpbmdhcnRlbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIA0K cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLW1wbHMt dHAtcmluZy1wcm90ZWN0aW9uDQpSZXZpc2lvbjogICAgICAgICAgICAgICAgIDAxDQpUaXRsZTog ICAgICAgICAgICAgICAgICAgICAgICAgICAgQXBwbGljYWJpbGl0eSBvZiBNUExTLVRQIExpbmVh ciANClByb3RlY3Rpb24gZm9yIFJpbmcgVG9wb2xvZ2llcw0KQ3JlYXRpb24gZGF0ZTogICAgICAg ICAgICAyMDEyLTAyLTE1DQpXRyBJRDogICAgICAgICAgICAgICAgICAgICAgICAgICAgbXBscw0K TnVtYmVyIG9mIHBhZ2VzOiAyOA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2Vu dHMgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgdG8gYWRkcmVzcyB0aGUNCiAgIHJlcXVpcmVt ZW50cyBmb3IgcHJvdGVjdGlvbiBvZiByaW5nIHRvcG9sb2dpZXMgZm9yIE11bHRpLVByb3RvY29s DQogICBMYWJlbCBTd2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIExhYmVsIFN3 aXRjaGVkIFBhdGhzDQogICAoTFNQKSBvbiBtdWx0aXBsZSBsYXllcnMuICBUaGUgTVBMUy1UUCBS ZXF1aXJlbWVudHMgZG9jdW1lbnQNCiAgIHNwZWNpZmllcyBzcGVjaWZpYyBjcml0ZXJpYSBmb3Ig anVzdGlmaWNhdGlvbiBvZiBkZWRpY2F0ZWQgcHJvdGVjdGlvbg0KICAgbWVjaGFuaXNtIGZvciBw YXJ0aWN1bGFyIHRvcG9sb2dpZXMsIGluY2x1ZGluZyBvcHRpbWl6aW5nIHRoZSBudW1iZXINCiAg IG9mIE9BTSBlbnRpdGllcyBuZWVkZWQsIG1pbmltaXppbmcgdGhlIG51bWJlciBvZiBsYWJlbHMg Zm9yDQogICBwcm90ZWN0aW9uIHBhdGhzLCBtaW5pbWl6aW5nIHRoZSBudW1iZXIgb2YgcmVjb3Zl cnkgZWxlbWVudHMgaW4gdGhlDQogICBuZXR3b3JrLCBhbmQgbWluaW1pemluZyB0aGUgbnVtYmVy IG9mIGNvbnRyb2wgYW5kIG1hbmFnZW1lbnQNCiAgIHRyYW5zYWN0aW9ucyBuZWNlc3NhcnkuICBU aGUgZG9jdW1lbnQgcHJvcG9zZXMgYSBtZXRob2RvbG9neSBmb3IgcmluZw0KICAgcHJvdGVjdGlv biBiYXNlZCBvbiBleGlzdGluZyBNUExTLVRQIHN1cnZpdmFiaWxpdHkgbWVjaGFuaXNtcywNCiAg IHNwZWNpZmljYWxseSB0aG9zZSBkZWZpbmVkIGluIE1QTFMtVFAgTGluZWFyIFByb3RlY3Rpb24s IHdpdGhvdXQgdGhlDQogICBuZWVkIGZvciBzcGVjaWZpY2F0aW9uIG9mIG5ldyBjb25zdHJ1Y3Rz IG9yIHByb3RvY29scy4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgYSBqb2lu dCBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlDQogICAoSUVURikgLyBJbnRlcm5hdGlv bmFsIFRlbGVjb21tdW5pY2F0aW9ucyBVbmlvbiBUZWxlY29tbXVuaWNhdGlvbnMNCiAgIFN0YW5k YXJkaXphdGlvbiBTZWN0b3IgKElUVS1UKSBlZmZvcnQgdG8gaW5jbHVkZSBhbiBNUExTIFRyYW5z cG9ydA0KICAgUHJvZmlsZSB3aXRoaW4gdGhlIElFVEYgTVBMUyBhbmQgUFdFMyBhcmNoaXRlY3R1 cmVzIHRvIHN1cHBvcnQgdGhlDQogICBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0aW9uYWxpdGllcyBv ZiBhIHBhY2tldCB0cmFuc3BvcnQgbmV0d29yayBhcw0KICAgZGVmaW5lZCBieSB0aGUgSVRVLVQu DQoNCiAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUg bm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRo IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0K --=_alternative 003336FE482579A5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnlhYWNvdixoaTwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aSB0aGluayBpdCBub3QgY2xldmVyIG1l dGhvZCB0byBhcHBseQ0KMSsxIHByb3RlY3Rpb24gc29sdXRpb24gZm9yIHRoZSB0cmFmZmljIG9u IHRoZSByaW5nLiBhcyBpIGtub3csIDUwJSByZXNvdXJjZQ0KaXMgdXNlZCBmb3Igd29ya2luZyBw YXRoLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YW5kIGFub3Ro ZXIgNTAlIHJlc291cmNlIGlzIHVzZWQgdG8NCnByb3RlY3RpbmcgcGF0aCwgaWYgeW91IGFwcGx5 IDErMSBpbiBwMm1wIHN0ZWVyaW5nIHNvbHV0aW9uLCBpIHN1c3BlY3QNCnRoZSByZXNvdXJjZSBv ZiB0aGUgcmluZyBpcyBub3QgYWRlcXVhdGUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5hbmQgdW5kZXIgbm9ybWFsIGNvbmRpdGlvbiwgYXBwbHlpbmcNCjErMSBz b2x1dGlvbiB3aWxsIHdhc3RlIGRvdWJsZSB0aGUgcmVzb3VyY2Ugb2YgJm5ic3A7dGhlIHJpbmcu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zbyBpIHRo aW5rIHdlIHNob3VsZCBjb250aW51ZSB0byBjb25zaWRlcg0KYSBnb29kIHNvbHV0aW9uIGZvciBz dGVlcmluZyBwcm90ZWN0aW9uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+aXQgaXMgbXkgcGVyc29uYWwgb3BpbmlvbnMsIHRoYW5rIHlvdSE8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkIuUi48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxpdTxicj4NCjwvZm9udD4NCjx0YWJsZT4NCjx0 cj4NCjx0ZD4NCjxkaXYgYWxpZ249Y2VudGVyPjwvZGl2Pg0KPHRkPjwvdGFibGU+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7V2Vpbmdh cnRlbiwgWWFhY292DQooTlNOIC0gSUwvSG9kIEhhU2hhcm9uKSZxdW90OyAmbHQ7eWFhY292Lndl aW5nYXJ0ZW5AbnNuLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wMi0xNSAxNjowNDwvZm9udD4N Cjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7bXBs c0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnd1LmJvQHp0ZS5jb20uY24sIGRhaS54 dWVodWlAenRlLmNvbS5jbiwNCm1hcmNvLmNvcnNpQGFsdHJhbi5pdCwgZnJhbmNlc2NvLmZvbmRl bGxpQGVyaWNzc29uLmNvbTwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24NCmZvciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRm LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAxLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SGkgYWxsLDxicj4NCjxicj4NClRoaXMg bmV3IHZlcnNpb24gYWRkcmVzc2VzIHRoZSBjb21tZW50cyB0aGF0IHdlcmUgc3VibWl0dGVkIGR1 cmluZyB0aGUNCnBvbGwgZm9yIGFjY2VwdGFuY2UgYXMgYSBXRyBkcmFmdC48YnI+DQo8YnI+DQpQ bGVhc2UgbGV0IHRoZSBhdXRob3JzIGtub3cgaWYgdGhlcmUgYXJlIGFkZGl0aW9uYWwgcG9pbnRz IHRoYXQgc2hvdWxkDQpiZSBhZGRyZXNzZWQuPGJyPg0KPGJyPg0KQlIsPGJyPg0KWWFhY292IFdl aW5nYXJ0ZW48YnI+DQpOb2tpYSBTaWVtZW5zIE5ldHdvcmtzPGJyPg0KPGJyPg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBleHQgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSA8YnI+DQpTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDE1LCAyMDEyIDEwOjAyIEFNPGJyPg0KVG86IFdlaW5nYXJ0ZW4sIFlhYWNvdiAo TlNOIC0gSUwvSG9kIEhhU2hhcm9uKTxicj4NCkNjOiBXZWluZ2FydGVuLCBZYWFjb3YgKE5TTiAt IElML0hvZCBIYVNoYXJvbik7IHd1LmJvQHp0ZS5jb20uY247IGRhaS54dWVodWlAenRlLmNvbS5j bjsNClNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgZGllZ28uY2F2aWds aWFAZXJpY3Nzb24uY29tOyBtYXJjby5jb3JzaUBhbHRyYW4uaXQ7DQpmcmFuY2VzY28uZm9uZGVs bGlAZXJpY3Nzb24uY29tOyBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tOyBzdGJyeWFu dEBjaXNjby5jb208YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDEudHh0PGJyPg0KPGJyPg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDEudHh0 IGhhcyBiZWVuDQpzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFlhYWNvdiBXZWluZ2FydGVuIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxicj4NClJldmlzaW9uOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDswMTxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KQXBwbGljYWJpbGl0eSBvZiBNUExTLVRQIExpbmVhciBQ cm90ZWN0aW9uIGZvciBSaW5nIFRvcG9sb2dpZXM8YnI+DQpDcmVhdGlvbiBkYXRlOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsy MDEyLTAyLTE1PGJyPg0KV0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQptcGxzPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiAy ODxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiAmbmJzcDsgVGhpcyBkb2N1bWVudCBwcmVzZW50 cyBhbiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCB0byBhZGRyZXNzIHRoZTxicj4NCiAmbmJzcDsg cmVxdWlyZW1lbnRzIGZvciBwcm90ZWN0aW9uIG9mIHJpbmcgdG9wb2xvZ2llcyBmb3IgTXVsdGkt UHJvdG9jb2w8YnI+DQogJm5ic3A7IExhYmVsIFN3aXRjaGluZyBUcmFuc3BvcnQgUHJvZmlsZSAo TVBMUy1UUCkgTGFiZWwgU3dpdGNoZWQgUGF0aHM8YnI+DQogJm5ic3A7IChMU1ApIG9uIG11bHRp cGxlIGxheWVycy4gJm5ic3A7VGhlIE1QTFMtVFAgUmVxdWlyZW1lbnRzIGRvY3VtZW50PGJyPg0K ICZuYnNwOyBzcGVjaWZpZXMgc3BlY2lmaWMgY3JpdGVyaWEgZm9yIGp1c3RpZmljYXRpb24gb2Yg ZGVkaWNhdGVkIHByb3RlY3Rpb248YnI+DQogJm5ic3A7IG1lY2hhbmlzbSBmb3IgcGFydGljdWxh ciB0b3BvbG9naWVzLCBpbmNsdWRpbmcgb3B0aW1pemluZyB0aGUgbnVtYmVyPGJyPg0KICZuYnNw OyBvZiBPQU0gZW50aXRpZXMgbmVlZGVkLCBtaW5pbWl6aW5nIHRoZSBudW1iZXIgb2YgbGFiZWxz IGZvcjxicj4NCiAmbmJzcDsgcHJvdGVjdGlvbiBwYXRocywgbWluaW1pemluZyB0aGUgbnVtYmVy IG9mIHJlY292ZXJ5IGVsZW1lbnRzIGluDQp0aGU8YnI+DQogJm5ic3A7IG5ldHdvcmssIGFuZCBt aW5pbWl6aW5nIHRoZSBudW1iZXIgb2YgY29udHJvbCBhbmQgbWFuYWdlbWVudDxicj4NCiAmbmJz cDsgdHJhbnNhY3Rpb25zIG5lY2Vzc2FyeS4gJm5ic3A7VGhlIGRvY3VtZW50IHByb3Bvc2VzIGEg bWV0aG9kb2xvZ3kNCmZvciByaW5nPGJyPg0KICZuYnNwOyBwcm90ZWN0aW9uIGJhc2VkIG9uIGV4 aXN0aW5nIE1QTFMtVFAgc3Vydml2YWJpbGl0eSBtZWNoYW5pc21zLDxicj4NCiAmbmJzcDsgc3Bl Y2lmaWNhbGx5IHRob3NlIGRlZmluZWQgaW4gTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiwgd2l0 aG91dA0KdGhlPGJyPg0KICZuYnNwOyBuZWVkIGZvciBzcGVjaWZpY2F0aW9uIG9mIG5ldyBjb25z dHJ1Y3RzIG9yIHByb3RvY29scy48YnI+DQo8YnI+DQogJm5ic3A7IFRoaXMgZG9jdW1lbnQgaXMg YSBwcm9kdWN0IG9mIGEgam9pbnQgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzaw0KRm9yY2U8YnI+ DQogJm5ic3A7IChJRVRGKSAvIEludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVuaW9u IFRlbGVjb21tdW5pY2F0aW9uczxicj4NCiAmbmJzcDsgU3RhbmRhcmRpemF0aW9uIFNlY3RvciAo SVRVLVQpIGVmZm9ydCB0byBpbmNsdWRlIGFuIE1QTFMgVHJhbnNwb3J0PGJyPg0KICZuYnNwOyBQ cm9maWxlIHdpdGhpbiB0aGUgSUVURiBNUExTIGFuZCBQV0UzIGFyY2hpdGVjdHVyZXMgdG8gc3Vw cG9ydA0KdGhlPGJyPg0KICZuYnNwOyBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0aW9uYWxpdGllcyBv ZiBhIHBhY2tldCB0cmFuc3BvcnQgbmV0d29yaw0KYXM8YnI+DQogJm5ic3A7IGRlZmluZWQgYnkg dGhlIElUVS1ULjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQ8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjxicj4NCjwvdHQ+PC9m b250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0 eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZu YnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3Bl cnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJz cDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVu dGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNw O29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5i c3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNw O3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZu YnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5i c3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNw O2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9y Jm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7 YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7 dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlm eSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2Uu Jm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4m bmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJz cDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 003336FE482579A5_=-- From pabloisnot@gmail.com Wed Feb 15 07:30: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 C1EB321F8570 for ; Wed, 15 Feb 2012 07:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.463, 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 exG5goLWQQ1H for ; Wed, 15 Feb 2012 07:30:29 -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 0AFEB21F8548 for ; Wed, 15 Feb 2012 07:30:28 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1893940obb.31 for ; Wed, 15 Feb 2012 07:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=cgjb/umJyU+DE8e0x6pc50cqg2WOdWQwGqKagp9htlo=; b=vYAfgWe1uFZ6cRhbJ+sjgz7DRcC3rmUyDYCdt1GI6BvZ+UZH1hZgnq8N2TtPhGc8HK UAIMrQ13amBkxbxZpafQriyLknFlOndI+qjSR7U7rChZbRt5FcIB0TdhcEb5EdpYFtyO e2/h/muJEckPz5hQopYwjsP57qsHoBkgHJNRg= MIME-Version: 1.0 Received: by 10.182.89.65 with SMTP id bm1mr18483599obb.52.1329319828711; Wed, 15 Feb 2012 07:30:28 -0800 (PST) Received: by 10.182.42.137 with HTTP; Wed, 15 Feb 2012 07:30:28 -0800 (PST) Date: Wed, 15 Feb 2012 10:30:28 -0500 Message-ID: From: Pablo Frank To: mpls@ietf.org Content-Type: multipart/alternative; boundary=f46d0447a0012ee9a104b90264fe Subject: [mpls] Question about Entropy labels + GAL 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, 15 Feb 2012 15:30:29 -0000 --f46d0447a0012ee9a104b90264fe Content-Type: text/plain; charset=ISO-8859-1 I'm working on implementation for entropy labels and I have a question about draft-ietf-mpls-entropy-label-01. Consider a scenario where I have received the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is unnecessary. Following the procedures detailed in 4.3, the datapath would lookup label x and see that it is expecting a possible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 payload. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. If I follow the procedures in 4.3, the datapath would end up popping the GAL or the explicit NULL label (thinking they are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous behaviour). The only additional guidance that the draft gives is in section 6 where it suggests that GAL could be treated as an application label. But that doesn't seem helpful since the LSP label must *also *be an application label (to handle the non-GAL case) and will always be encountered first during label disposition. Also, presumably I don't want all GALs to expect entropy so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled application label or an ELI, that it essentially must do a "deferred pop of BOS label". In other words, if the datapath encounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels until it hits the BOS label, which it must pop. While certainly possible, this is a lot more convoluted and difficult to implement than what is specified in the draft. Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo --f46d0447a0012ee9a104b90264fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm working on implementation for entropy labels and I have a question = about=A0draft-ietf-mpls-entropy-label-01. =A0Consider a scenario where I ha= ve received the following:

... | LSP label x | Entropy l= abel | IPv4 payload | ...

Assume that I've signaled that the LSP label wants = entropy and an ELI is unnecessary. =A0Following the procedures detailed in = 4.3, the datapath would lookup label x and see that it is expecting a possi= ble entropy label and since x is not BOS, it pops the next label and then b= egins processing the IPv4 payload. =A0So far, so good. =A0

However, I believe the following is legal as well:

... | LSP label x | GAL label | Entropy label | BFD pa= yload | ...

Alternatively, an equally vexing scena= rio is:

... | LSP label x | IPv4 explicit NULL | Entropy l= abel | IPv4 payload | ...

There are probably other= reserved labels that are applicable as well.

In either case, the draft doesn't clearly state what's supposed to = happen. =A0If I follow the procedures in 4.3, the datapath would end up pop= ping the GAL or the explicit NULL label (thinking they are entropy labels) = and would then attempt to lookup the entropy label (which would result in e= rroneous behaviour). =A0 The only additional guidance that the draft gives = is in section 6 where it suggests that GAL could be treated as an applicati= on label. =A0But that doesn't seem helpful since the LSP label must = also be an application label (to handle the non-GAL case) and will alwa= ys be encountered first during label disposition. =A0Also, presumably I don= 't want all GALs to expect entropy so there's an implied scoping of= GAL.

It seems to me that when a datapath encounters an= entropy-enabled application label or an ELI, that it essentially must do a= "deferred pop of BOS label". =A0In other words, if the datapath = encounters an entropy-enabled AL or an ELI, it must make a note of it and c= ontinue processing labels until it hits the BOS label, which it must pop. = =A0While certainly possible, this is a lot more convoluted and difficult to= implement than what is specified in the draft. =A0Is this really the desir= ed behaviour?

The same question applies to type-4 VCCV with flow labe= ls.

regards,
Pablo

--f46d0447a0012ee9a104b90264fe-- From jdrake@juniper.net Wed Feb 15 13:28: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 2FB3621E809B for ; Wed, 15 Feb 2012 13:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[AWL=2.301, 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 P4xk+Vpe5IrL for ; Wed, 15 Feb 2012 13:28:16 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1BC21E8065 for ; Wed, 15 Feb 2012 13:28:15 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTzwjbhFgV7yt9GIhLd5/ZpN+u/CCEpzx@postini.com; Wed, 15 Feb 2012 13:28:15 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 15 Feb 2012 13:26:02 -0800 From: John E Drake To: Pablo Frank , "mpls@ietf.org" Date: Wed, 15 Feb 2012 13:26:00 -0800 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: Aczr9svq89idVYJbTj+gjzynuLRELAAMTOzQ Message-ID: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f8e27f27-03b2-4c3e-9447-119194e72cb6 Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A55C7056F0EMBX01HQjnprn_" MIME-Version: 1.0 Subject: Re: [mpls] Question about Entropy labels + GAL 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, 15 Feb 2012 21:28:18 -0000 --_000_5E893DB832F57341992548CDBB333163A55C7056F0EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pablo, Based upon Kireeti's update in Taipei, we seem to going towards using a res= erved label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pab= lo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question abou= t draft-ietf-mpls-entropy-label-01. Consider a scenario where I have recei= ved the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is un= necessary. Following the procedures detailed in 4.3, the datapath would lo= okup label x and see that it is expecting a possible entropy label and sinc= e x is not BOS, it pops the next label and then begins processing the IPv4 = payload. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the G= AL or the explicit NULL label (thinking they are entropy labels) and would = then attempt to lookup the entropy label (which would result in erroneous b= ehaviour). The only additional guidance that the draft gives is in sectio= n 6 where it suggests that GAL could be treated as an application label. B= ut that doesn't seem helpful since the LSP label must also be an applicatio= n label (to handle the non-GAL case) and will always be encountered first d= uring label disposition. Also, presumably I don't want all GALs to expect = entropy so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicati= on label or an ELI, that it essentially must do a "deferred pop of BOS labe= l". In other words, if the datapath encounters an entropy-enabled AL or an= ELI, it must make a note of it and continue processing labels until it hit= s the BOS label, which it must pop. While certainly possible, this is a lo= t more convoluted and difficult to implement than what is specified in the = draft. Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo --_000_5E893DB832F57341992548CDBB333163A55C7056F0EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pablo,

 

=

Based upon Kireeti’s update in Taipei, we= seem to going towards using a reserved label for ELI and making it always = required.

 

Thanks,

 

John  

 =

From: mpls-bounc= es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank<= br>Sent: Wednesday, February 15, 2012 7:30 AM
To: mpls@iet= f.org
Subject: [mpls] Question about Entropy labels + GAL

 

I'm working on implementation for entropy labels and I have a= question about draft-ietf-mpls-entropy-label-01.  Consider a sce= nario where I have received the following:

 

... | LSP labe= l x | Entropy label | IPv4 payload | ...

 

Assume th= at I've signaled that the LSP label wants entropy and an ELI is unnecessary= .  Following the procedures detailed in 4.3, the datapath would lookup= label x and see that it is expecting a possible entropy label and since x = is not BOS, it pops the next label and then begins processing the IPv4 payl= oad.  So far, so good.  

 

However, I belie= ve the following is legal as well:

 

... | LSP label = x | GAL label | Entropy label | BFD payload | ...

=

 

A= lternatively, an equally vexing scenario is:

 

.= .. | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ...<= o:p>

 

There are probably other reserved labels that are a= pplicable as well.

 = ;

In either case, the draft doesn'= t clearly state what's supposed to happen.  If I follow the procedures= in 4.3, the datapath would end up popping the GAL or the explicit NULL lab= el (thinking they are entropy labels) and would then attempt to lookup the = entropy label (which would result in erroneous behaviour).   The only = additional guidance that the draft gives is in section 6 where it suggests = that GAL could be treated as an application label.  But that doesn't s= eem helpful since the LSP label must also be an application label (t= o handle the non-GAL case) and will always be encountered first during labe= l disposition.  Also, presumably I don't want all GALs to expect entro= py so there's an implied scoping of GAL.

 

It s= eems to me that when a datapath encounters an entropy-enabled application l= abel or an ELI, that it essentially must do a "deferred pop of BOS lab= el".  In other words, if the datapath encounters an entropy-enabl= ed AL or an ELI, it must make a note of it and continue processing labels u= ntil it hits the BOS label, which it must pop.  While certainly possib= le, this is a lot more convoluted and difficult to implement than what is s= pecified in the draft.  Is this really the desired behaviour?

 

The same question applies to type-4 VCCV with flow labels.<= o:p>

 

regards,

Pablo

 

= --_000_5E893DB832F57341992548CDBB333163A55C7056F0EMBX01HQjnprn_-- From pabloisnot@gmail.com Wed Feb 15 14:24: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 591B221E8092; Wed, 15 Feb 2012 14:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.371, 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 39XWo0AMnZcw; Wed, 15 Feb 2012 14:24:11 -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 3F74921E8032; Wed, 15 Feb 2012 14:24:11 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2408084obb.31 for ; Wed, 15 Feb 2012 14:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QW/n6P1HKzz1Y0btVy1BV1vprTJko15HKrsfVBQiut8=; b=JSimeIxtIIskc0qRuryI+7Nz7R8o0SMnwnLdoPVhT6Iic9QX6WcdGV1++iVk3Qwa3b P9rV9BP/KUqAxjIvFUl0zaiZXff+jDLRJ+JBw7kL0ubUMLdXc22IMLo0PKYA2NSTfIZo SURLqxb/I1L5J/25MYG/MfMrmpPcR7ftmpU1Y= MIME-Version: 1.0 Received: by 10.182.89.65 with SMTP id bm1mr19606310obb.52.1329344650877; Wed, 15 Feb 2012 14:24:10 -0800 (PST) Received: by 10.182.42.137 with HTTP; Wed, 15 Feb 2012 14:24:10 -0800 (PST) In-Reply-To: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> Date: Wed, 15 Feb 2012 17:24:10 -0500 Message-ID: From: Pablo Frank To: John E Drake Content-Type: multipart/alternative; boundary=f46d0447a001b31c0f04b9082b20 Cc: "mpls@ietf.org" , pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL 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, 15 Feb 2012 22:24:12 -0000 --f46d0447a001b31c0f04b9082b20 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat pseudowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs when flow labels are present? That seems too bad since the main advantage of type-4 VCCV seems to be to save a few bytes on the wire. This puts the overhead right back in so it may be more attractive to run fat PWEs with type-1 VCCV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake wrote: > Pablo,**** > > ** ** > > Based upon Kireeti=92s update in Taipei, we seem to going towards using a > reserved label for ELI and making it always required.**** > > ** ** > > Thanks,**** > > ** ** > > John **** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Pablo Frank > *Sent:* Wednesday, February 15, 2012 7:30 AM > *To:* mpls@ietf.org > *Subject:* [mpls] Question about Entropy labels + GAL**** > > ** ** > > I'm working on implementation for entropy labels and I have a question > about draft-ietf-mpls-entropy-label-01. Consider a scenario where I have > received the following:**** > > ** ** > > ... | LSP label x | Entropy label | IPv4 payload | ...**** > > ** ** > > Assume that I've signaled that the LSP label wants entropy and an ELI is > unnecessary. Following the procedures detailed in 4.3, the datapath woul= d > lookup label x and see that it is expecting a possible entropy label and > since x is not BOS, it pops the next label and then begins processing the > IPv4 payload. So far, so good. **** > > ** ** > > However, I believe the following is legal as well:**** > > ** ** > > ... | LSP label x | GAL label | Entropy label | BFD payload | ...**** > > ** ** > > Alternatively, an equally vexing scenario is:**** > > ** ** > > ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | .= .. > **** > > ** ** > > There are probably other reserved labels that are applicable as well.**** > > ** ** > > In either case, the draft doesn't clearly state what's supposed to happen= . > If I follow the procedures in 4.3, the datapath would end up popping the > GAL or the explicit NULL label (thinking they are entropy labels) and wou= ld > then attempt to lookup the entropy label (which would result in erroneous > behaviour). The only additional guidance that the draft gives is in > section 6 where it suggests that GAL could be treated as an application > label. But that doesn't seem helpful since the LSP label must *also *be > an application label (to handle the non-GAL case) and will always be > encountered first during label disposition. Also, presumably I don't wan= t > all GALs to expect entropy so there's an implied scoping of GAL.**** > > ** ** > > It seems to me that when a datapath encounters an entropy-enabled > application label or an ELI, that it essentially must do a "deferred pop = of > BOS label". In other words, if the datapath encounters an entropy-enable= d > AL or an ELI, it must make a note of it and continue processing labels > until it hits the BOS label, which it must pop. While certainly possible= , > this is a lot more convoluted and difficult to implement than what is > specified in the draft. Is this really the desired behaviour?**** > > ** ** > > The same question applies to type-4 VCCV with flow labels.**** > > ** ** > > regards,**** > > Pablo**** > > ** ** > --f46d0447a001b31c0f04b9082b20 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ah, good. =A0That certainly makes things more deterministic. =A0

I guess the question now becomes how will this affect type-4 VCCV = on fat pseudowires (RFC 6391)? =A0Will type-4 VCCV have to mandate the use = of ELIs when flow labels are present? =A0That seems too bad since the main = advantage of type-4 VCCV seems to be to save a few bytes on the wire. =A0Th= is puts the overhead right back in so it may be more attractive to run fat = PWEs with type-1 VCCV...

Pablo

On Wed, Feb 15,= 2012 at 4:26 PM, John E Drake <jdrake@juniper.net> wrote:<= br>

Pablo,

=A0

Based upon Kireeti=92s update in Taipei, we s= eem to going towards using a reserved label for ELI and making it always re= quired.

=A0<= /p>

Thanks,<= /span>

=A0<= /p>

John =A0=

=A0<= /p>

From: mpls-bounc= es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: mpls@ietf.org
Subject: [mpls] Question about Entropy labels + GAL

=A0

I'm working on implementation for entropy labels and I have a q= uestion about=A0draft-ietf-mpls-entropy-label-01. =A0Consider a scenario wh= ere I have received the following:

=A0

... | LSP label x | Entropy label | IPv4 payload | ...

=A0

Assume that I've signaled that the LSP label wants entropy and an ELI i= s unnecessary. =A0Following the procedures detailed in 4.3, the datapath wo= uld lookup label x and see that it is expecting a possible entropy label an= d since x is not BOS, it pops the next label and then begins processing the= IPv4 payload. =A0So far, so good. =A0

=A0

However, I believe the following is legal as well:=

=A0

<= p class=3D"MsoNormal"> ... | LSP label x | GAL label | Entropy label | BFD payload | ...=

=A0

<= p class=3D"MsoNormal">Alternatively, an equally vexing scenario is:<= u>

=A0

... | LSP label x | IPv4 explicit NULL | Entropy label |= IPv4 payload | ...

<= /u>=A0

There are probably other reserved labels = that are applicable as well.

=A0

In either case,= the draft doesn't clearly state what's supposed to happen. =A0If I= follow the procedures in 4.3, the datapath would end up popping the GAL or= the explicit NULL label (thinking they are entropy labels) and would then = attempt to lookup the entropy label (which would result in erroneous behavi= our). =A0 The only additional guidance that the draft gives is in section 6= where it suggests that GAL could be treated as an application label. =A0Bu= t that doesn't seem helpful since the LSP label must also be an = application label (to handle the non-GAL case) and will always be encounter= ed first during label disposition. =A0Also, presumably I don't want all= GALs to expect entropy so there's an implied scoping of GAL.=

=A0

It seems to me that when a datapath encounters an entro= py-enabled application label or an ELI, that it essentially must do a "= ;deferred pop of BOS label". =A0In other words, if the datapath encoun= ters an entropy-enabled AL or an ELI, it must make a note of it and continu= e processing labels until it hits the BOS label, which it must pop. =A0Whil= e certainly possible, this is a lot more convoluted and difficult to implem= ent than what is specified in the draft. =A0Is this really the desired beha= viour?

=A0

The same question applies to type-4 VCCV with flow labels.

=A0

regards,

Pablo

=A0=


--f46d0447a001b31c0f04b9082b20-- From internet-drafts@ietf.org Wed Feb 15 20:23: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 472F021F85A7; Wed, 15 Feb 2012 20:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 4pRCnIp+9E4K; Wed, 15 Feb 2012 20:23:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61F121F85A1; Wed, 15 Feb 2012 20:23:30 -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: 3.64p2 Message-ID: <20120216042330.14136.36010.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2012 20:23:30 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-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: Thu, 16 Feb 2012 04:23:35 -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 IP and PW Capability Author(s) : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-01.txt Pages : 11 Date : 2012-02-15 Currently, no LDP capability is exchanged for LDP applications like IP label switching and L2VPN/PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session may be established for some other applications like ICCP. This document proposes a solution by which an LDP speaker announces its disinterest or non- support for IP label switching or L2VPN/PW application, hence disabling corresponding application state exchange over the established LDP session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ip-pw-capability-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-ip-pw-capability-01.= txt From Alexander.Vainshtein@ecitele.com Wed Feb 15 22:24: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 37BE321F851E for ; Wed, 15 Feb 2012 22:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 gmC4RKONnZ6L for ; Wed, 15 Feb 2012 22:24:26 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 4BA8621F850F for ; Wed, 15 Feb 2012 22:24:22 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1329373410!54455154!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 25466 invoked from network); 16 Feb 2012 06:23:30 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-6.tower-27.messagelabs.com with SMTP; 16 Feb 2012 06:23:30 -0000 X-AuditID: 93eaf2e7-b7fb46d000005f52-8c-4f3cacdcca28 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 3E.D1.24402.CDCAC3F4; Thu, 16 Feb 2012 09:14:36 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 16 Feb 2012 08:24:20 +0200 From: Alexander Vainshtein To: Pablo Frank , John E Drake Date: Thu, 16 Feb 2012 08:22:36 +0200 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: AczsMFnBTnRSQc/CQ/OmxQcJJA9zewAQHM7a Message-ID: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net>, 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_A3C5DF08D38B6049839A6F553B331C76011659266622ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUYRTl25mdHVcnJnPdLynapjKorN0euJpbYQ8Uiq0MAql0mv3amdqd HXbWyDQUoYf7o3xApT002iTLMs1eUFRGVEZZkRSSkb3MNRRMiJ4205gJ0fw6c865594Z7iWx 6KAhjhTEAPKLrIchjHh5uH8g4UVditPa2jrRfrhjsb39RK3efqDnDmHf29+EL8LTrlR2GNJC oS+6tGdFbYaVWGYhSGFF0RdgA8jiQjLnYFb6ha0sl8tYBJeDsTEWycNyyIvEgINhJQmJLmaB 0fLPk6LYBNGCRM7nEkS3g0nPcCbY7fOSEmzMgvhJtjnzjWt4QbagBC8reCxeJMusG1kUJrsJ 4y/eKCKkb+K2d3VPiUJwfH0QRJCQngsfNx3FNBwLH72sJ1QcTV8HsLbXGQRGBe8HsORat14V CNoBG093/DbF0OlwIHxHp2KMXgJfdrUYVIzTU2BfTQUeBCQ5hk6ENeUFmt0OqzvaMZWOoWfD Q73LVZqiV8FXRd2E1uoZgG2Xw0AVIhSh6P59XMVAme1zS91QKzNsf1ul02amYehq69D8Jtj9 5qde85vgi931QPP7YG/FgEFrNhreq3iLa/6x8ObJ53gJiK0cEVs5oqRyRInGW2HfwypMw9Nh zbGeITwLNgw8ACP5amA4BUyCRwps9LqttpmIEwLIg2ZyPm8j0Bap6zL4WjW5GdAkYKKoRQUp zmg9u1XO9TaDsaSOMVHOaoUatdHnyuVZmc/y53iQ3AwgiTExVPJORaNcbO525Pf9kZYqP78U i4vkfMrKioGsOVbr/18YM/WO+7gimnYri7kFIQn5/+SMI0kGUqvV9qP9yI22bRI8gb+yjoxQ x4hSxshTPZQssV5ZcGt6C5gYZ6Y8qkCrAp8jDteqJ1QwODgYBmblo8dQu1RXlHJgw9VhJVin BCd+SFaDlaMZluIKgZcoWxfqW5sDrMlY25GCTnbZd+KK6ZLwgS8z8z8aLjyZOy7+4EK9r+v8 46TQl9j+/GI5I5uROvOmb5YeRqaeO3u3dEfX7X2lry+yMUm7g/yE9183ZBV/qs0bv6e8c/HR Wxw+I2thNrqQX38pP37q6shMo2FHtr2kfllq2pnye8XdDC7zrG0a5pfZXwR+yPsdBAAA Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] Question about Entropy labels + GAL 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, 16 Feb 2012 06:24:27 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011659266622ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Pablo, John and all, A couple of comments: 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 has re= laxed the original requirement for GAL being at the bottom of stack that hav= e been defined in RFC 5586. 2. My reading of RFC 6391 is that it mandates the flow label to be at the= bottom of the label stack for PW packets carrying user data. And it does no= t provide for ELI usage anywhere, be it a reserved label or a signaled one. 3. To the best of my understanding, the situation when GAL is used for fat= PWs is not explicitly defined. Inserting GAL between the PW label and flow= label (with the ACH header immediately following the label stack) seems to= be fully compatible with both RFC 6423 and RFC 6391. Maybe this format shou= ld be explicitly defined as the correct one? Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo Frank= [pabloisnot@gmail.com] Sent: Thursday, February 16, 2012 12:24 AM To: John E Drake Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat pse= udowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs when= flow labels are present? That seems too bad since the main advantage of ty= pe-4 VCCV seems to be to save a few bytes on the wire. This puts the overhe= ad right back in so it may be more attractive to run fat PWEs with type-1 VC= CV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake > wrote: Pablo, Based upon Kireeti=92s update in Taipei, we seem to going towards using a re= served label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-bounc= es@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question about= draft-ietf-mpls-entropy-label-01. Consider a scenario where I have receive= d the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is unn= ecessary. Following the procedures detailed in 4.3, the datapath would look= up label x and see that it is expecting a possible entropy label and since x= is not BOS, it pops the next label and then begins processing the IPv4 payl= oad. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the GA= L or the explicit NULL label (thinking they are entropy labels) and would th= en attempt to lookup the entropy label (which would result in erroneous beha= viour). The only additional guidance that the draft gives is in section 6= where it suggests that GAL could be treated as an application label. But t= hat doesn't seem helpful since the LSP label must also be an application lab= el (to handle the non-GAL case) and will always be encountered first during= label disposition. Also, presumably I don't want all GALs to expect entrop= y so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicatio= n label or an ELI, that it essentially must do a "deferred pop of BOS label"= . In other words, if the datapath encounters an entropy-enabled AL or an EL= I, it must make a note of it and continue processing labels until it hits th= e BOS label, which it must pop. While certainly possible, this is a lot mor= e convoluted and difficult to implement than what is specified in the draft.= Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76011659266622ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
Pablo, John and all,
A couple of comments:
 
  1. Following a long discussion on the PWE3 WG mailing list RFC 6423 ha= s relaxed the original requirement for GAL being at the bottom o= f stack that have been defined in RFC 5586.
  2. My reading of RFC 6391 is that it mandates the flow label to b= e at the bottom of the label stack for PW packets carrying user= data. And it does not provide for ELI usage anywhere, be it a reserved labe= l or a signaled one.
  3. To the best of my understanding, the situation when GAL is used for= fat PWs is not explicitly defined. Inserting GAL between the PW label= and flow label (with the ACH header immediately following the label stack)= seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the co= rrect one?

Regards,

     Sasha

 

 
 
 
 
 
 
 
From: mpls-bounces= @ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo Frank [pabloisnot@gmail= .com]
Sent: Thursday, February 16, 2012 12:24 AM
To: John E Drake
Cc: mpls@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] Question about Entropy labels + GAL

Ah, good.  That certainly makes things more deterministic.  

I guess the question now becomes how will this affect type-4 VCCV on fa= t pseudowires (RFC 6391)?  Will type-4 VCCV have to mandate the use of= ELIs when flow labels are present?  That seems too bad since the main= advantage of type-4 VCCV seems to be to save a few bytes on the wire.  This puts the overhead right back in so= it may be more attractive to run fat PWEs with type-1 VCCV...

Pablo

On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.net>= wrote:

Pablo,

 

Based upon Kireeti=92s update in Taipei, we= seem to going towards using a reserved label for ELI and making it always r= equired.

 

Thanks,

 

John  

 

From: mpls-bounces@ietf.org [mailto:<= a href=3D"mailto:mpls-bounces@ietf.org">mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: mpls@ietf.org
Subject: [mpls] Question about Entropy labels + GAL=

 

I'm working on implementation for entropy labels and= I have a question about draft-ietf-mpls-entropy-label-01.  Consid= er a scenario where I have received the following:

 

... | LSP label x | Entropy label | IPv4 payload | ..= .

 

Assume that I've signaled that the LSP label wants en= tropy and an ELI is unnecessary.  Following the procedures detailed in= 4.3, the datapath would lookup label x and see that it is expecting a possi= ble entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 payload. &n= bsp;So far, so good.  

 

However, I believe the following is legal as well:=

 

... | LSP label x | GAL label | Entropy label | BFD p= ayload | ...

 

Alternatively, an equally vexing scenario is:<= u>

 

... | LSP label x | IPv4 explicit NULL | Entropy labe= l | IPv4 payload | ...

 

There are probably other reserved labels that are app= licable as well.

 

In either case, the draft doesn't clearly state what'= s supposed to happen.  If I follow the procedures in 4.3, the datapath= would end up popping the GAL or the explicit NULL label (thinking they are= entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous behaviour). &n= bsp; The only additional guidance that the draft gives is in section 6 where= it suggests that GAL could be treated as an application label.  But th= at doesn't seem helpful since the LSP label must also be an application label (to handle the non-GAL case) and w= ill always be encountered first during label disposition.  Also, presum= ably I don't want all GALs to expect entropy so there's an implied scoping o= f GAL.

 

It seems to me that when a datapath encounters an ent= ropy-enabled application label or an ELI, that it essentially must do a &quo= t;deferred pop of BOS label".  In other words, if the datapath enc= ounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels until it hits the BOS labe= l, which it must pop.  While certainly possible, this is a lot more con= voluted and difficult to implement than what is specified in the draft. &nbs= p;Is this really the desired behaviour?

 

The same question applies to type-4 VCCV with flow la= bels.

 

regards,

Pablo

 


This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76011659266622ILPTMAIL02e_-- From pabloisnot@gmail.com Thu Feb 16 08:22: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 5D0DD21F8833; Thu, 16 Feb 2012 08:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.309, 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 T2SJKEiynQaj; Thu, 16 Feb 2012 08:22:06 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E444D21F8830; Thu, 16 Feb 2012 08:22:05 -0800 (PST) Received: by ggnq2 with SMTP id q2so1523850ggn.31 for ; Thu, 16 Feb 2012 08:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SjNc7nZnYigSwOntli3uKdN6KVAWzoF8V2QrjV2XfsY=; b=msbj2zkadn/heBL3jnoyWxfigBK1JaTzVxwYrUC6aO7QjtOUH6dmeMv0cYH/XcGsjk TshZ+zmrDp7qRRqsCT1nLQ7BbPAFVlfeucCJ0a9nvxVC61iHGqUus8nwht6Qq8AxN+nO 19bQ//KQOrCkVRmdwDFqcVxaqqPM9kM1JynPY= MIME-Version: 1.0 Received: by 10.60.1.230 with SMTP id 6mr1116051oep.42.1329409325420; Thu, 16 Feb 2012 08:22:05 -0800 (PST) Received: by 10.182.42.137 with HTTP; Thu, 16 Feb 2012 08:22:05 -0800 (PST) In-Reply-To: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> Date: Thu, 16 Feb 2012 11:22:05 -0500 Message-ID: From: Pablo Frank To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=e89a8fb1ffa49a52a604b9173ab8 Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Question about Entropy labels + GAL 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, 16 Feb 2012 16:22:07 -0000 --e89a8fb1ffa49a52a604b9173ab8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Sasha. I completely concur with your points 1 and 2. As for point #3, that seems like the logical conclusion. However, I think there's still a bit of awkwardness around implementing this. Both the original entropy-label draft and RFC 6391 have assumed a simple pop-pop logic when you encounter an entropy-enabled AL or a flow-enabled PW. The moment GAL, or any other reserved label gets thrown into the mix, the label disposition logic gets suddenly more complex. Instead of pop-pop, the hardware will have to do more complicated logic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". While I have very programmable hardware at my disposal, I prefer elegant and simple and this feels wrong. It sounds like the authors of the entropy label draft have recognized this problem and are now moving towards mandating the use of a reserved ELI which unambiguously implies that the next label is entropy (so the hardware can go back to having simple pop-pop logic when it sees a reserved ELI). Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the situation is unambiguous. If I encounter any of these types of PWEs with flow-enabled, I can do a pop-pop. If for type-4 VCCV, we assume that the GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try and dispose of the GAL and flow label correctly. A reserved ELI could help disambiguate the situation in this case but this makes running type-4 VCCV with flow labels unattractive compared to type-1 VCCV. regards, Pablo On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Pablo, John and all, > A couple of comments: > > > 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 > has relaxed the original requirement for GAL being at the bottom of > stack that have been defined in RFC 5586. > 2. My reading of RFC 6391 is that it mandates the flow label to be at > the bottom of the label stack for PW packets carrying user data. And > it does not provide for ELI usage anywhere, be it a reserved label or = a > signaled one. > 3. To the best of my understanding, the situation when GAL is used for > fat PWs is not explicitly defined. Inserting GAL between the PW label = and > flow label (with the ACH header immediately following the label stack) > seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe th= is > format should be explicitly defined as the correct one? > > Regards, > > Sasha > > > > > > > > > > ------------------------------ > *From:* mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo > Frank [pabloisnot@gmail.com] > *Sent:* Thursday, February 16, 2012 12:24 AM > *To:* John E Drake > *Cc:* mpls@ietf.org; pwe3@ietf.org > *Subject:* Re: [mpls] Question about Entropy labels + GAL > > Ah, good. That certainly makes things more deterministic. > > I guess the question now becomes how will this affect type-4 VCCV on fat > pseudowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs > when flow labels are present? That seems too bad since the main advantag= e > of type-4 VCCV seems to be to save a few bytes on the wire. This puts th= e > overhead right back in so it may be more attractive to run fat PWEs with > type-1 VCCV... > > Pablo > > On Wed, Feb 15, 2012 at 4:26 PM, John E Drake wrote: > >> Pablo,**** >> >> **** >> >> Based upon Kireeti=92s update in Taipei, we seem to going towards using = a >> reserved label for ELI and making it always required.**** >> >> **** >> >> Thanks,**** >> >> **** >> >> John **** >> >> **** >> >> *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf >> Of *Pablo Frank >> *Sent:* Wednesday, February 15, 2012 7:30 AM >> *To:* mpls@ietf.org >> *Subject:* [mpls] Question about Entropy labels + GAL**** >> >> **** >> >> I'm working on implementation for entropy labels and I have a question >> about draft-ietf-mpls-entropy-label-01. Consider a scenario where I hav= e >> received the following:**** >> >> **** >> >> ... | LSP label x | Entropy label | IPv4 payload | ...**** >> >> **** >> >> Assume that I've signaled that the LSP label wants entropy and an ELI is >> unnecessary. Following the procedures detailed in 4.3, the datapath wou= ld >> lookup label x and see that it is expecting a possible entropy label and >> since x is not BOS, it pops the next label and then begins processing th= e >> IPv4 payload. So far, so good. **** >> >> **** >> >> However, I believe the following is legal as well:**** >> >> **** >> >> ... | LSP label x | GAL label | Entropy label | BFD payload | ...**** >> >> **** >> >> Alternatively, an equally vexing scenario is:**** >> >> **** >> >> ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | >> ...**** >> >> **** >> >> There are probably other reserved labels that are applicable as well.***= * >> >> **** >> >> In either case, the draft doesn't clearly state what's supposed to >> happen. If I follow the procedures in 4.3, the datapath would end up >> popping the GAL or the explicit NULL label (thinking they are entropy >> labels) and would then attempt to lookup the entropy label (which would >> result in erroneous behaviour). The only additional guidance that the >> draft gives is in section 6 where it suggests that GAL could be treated = as >> an application label. But that doesn't seem helpful since the LSP label >> must *also *be an application label (to handle the non-GAL case) and >> will always be encountered first during label disposition. Also, >> presumably I don't want all GALs to expect entropy so there's an implied >> scoping of GAL.**** >> >> **** >> >> It seems to me that when a datapath encounters an entropy-enabled >> application label or an ELI, that it essentially must do a "deferred pop= of >> BOS label". In other words, if the datapath encounters an entropy-enabl= ed >> AL or an ELI, it must make a note of it and continue processing labels >> until it hits the BOS label, which it must pop. While certainly possibl= e, >> this is a lot more convoluted and difficult to implement than what is >> specified in the draft. Is this really the desired behaviour?**** >> >> **** >> >> The same question applies to type-4 VCCV with flow labels.**** >> >> **** >> >> regards,**** >> >> Pablo**** >> >> **** >> > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --e89a8fb1ffa49a52a604b9173ab8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Sasha. =A0I completely concur with your points 1 and 2.

As for point #3, that seems like the logical conclusion. =A0However,= I think there's still a bit of awkwardness around implementing this. = =A0Both the original entropy-label draft and RFC 6391 have assumed a simple= pop-pop logic when you encounter an entropy-enabled AL or a flow-enabled P= W. =A0The moment GAL, or any other reserved label gets thrown into the mix,= the label disposition logic gets suddenly more complex. =A0Instead of pop-= pop, the hardware will have to do more complicated logic like "IF this= is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF .= .., etc.". =A0While I have very programmable hardware at my disposal, = I prefer elegant and simple and this feels wrong.

It sounds like the authors of the entropy label draft h= ave recognized this problem and are now moving towards mandating the use of= a reserved ELI which unambiguously implies that the next label is entropy = (so the hardware can go back to having simple pop-pop logic when it sees a = reserved ELI).

Which brings me back to VCCV. =A0If I'm doing type-= 1,2,3 VCCV, the situation is unambiguous. =A0If I encounter any of these ty= pes of PWEs with flow-enabled, I can do a pop-pop. =A0If for type-4 VCCV, w= e assume that the GAL is between the PW label and flow label (which I think= was the intent), we're back to having ugly logic to try and dispose of= the GAL and flow label correctly. =A0A reserved ELI could help disambiguat= e the situation in this case but this makes running type-4 VCCV with flow l= abels unattractive compared to type-1 VCCV.

regards,
Pablo

On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein <Alexander.= Vainshtein@ecitele.com> wrote:
Pablo, John and all,
A couple of comments:
=A0
  1. Following a=A0long discussion on the PWE3 WG mailing list RFC 6423 has = relaxed the original=A0requirement for GAL being at the bottom of st= ack that have been defined in RFC 5586.
  2. My reading of=A0RFC 6391 is that it mandates the flow label to be = at the bottom of the label stack for PW packets=A0carrying user data= . And it does not provide for ELI usage anywhere, be it a reserved label or= a signaled one.
  3. To the best of my understanding, the situation when GAL is used fo= r fat PWs is not explicitly defined.=A0Inserting GAL between the PW label a= nd flow label (with the ACH header immediately following the label stack) s= eems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the c= orrect one?

Regards,

=A0=A0=A0=A0 Sasha

=A0

=A0
=A0
=A0
=A0
=A0
=A0
From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] = On Behalf Of Pablo Frank [pabloisnot@gmail.com]
Sent: Thursday, February 16, 2012 12:24 AM
To: John E Drake
Cc: mpls@ietf.org= ; pwe3@ietf.org<= br> Subject: Re: [mpls] Question about Entropy labels + GAL

Ah, good. =A0That certainly makes things more deterministic. =A0

I guess the question now becomes how will this affect type-4 VCCV on f= at pseudowires (RFC 6391)? =A0Will type-4 VCCV have to mandate the use of E= LIs when flow labels are present? =A0That seems too bad since the main adva= ntage of type-4 VCCV seems to be to save a few bytes on the wire. =A0This puts the overhead right back in so i= t may be more attractive to run fat PWEs with type-1 VCCV...

Pablo

On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.= net> wrote:

Pablo,

=A0

Based upon Kireeti=92s update i= n Taipei, we seem to going towards using a reserved label for ELI and makin= g it always required.

=A0

Thanks,

=A0

John =A0

=A0

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: mpls@ietf.org=
Subject: [mpls] Question about Entropy labels + GAL

=A0

I'm working on implementation for entropy labels= and I have a question about=A0draft-ietf-mpls-entropy-label-01. =A0Conside= r a scenario where I have received the following:

=A0

... | LSP label x | Entropy label | IPv4 payload | .= ..

=A0

Assume that I've signaled that the LSP label wan= ts entropy and an ELI is unnecessary. =A0Following the procedures detailed = in 4.3, the datapath would lookup label x and see that it is expecting a po= ssible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 payload. = =A0So far, so good. =A0

=A0

However, I believe the following is legal as well:

=A0

... | LSP label x | GAL label | Entropy label | BFD = payload | ...

=A0

Alternatively, an equally vexing scenario is:=

=A0

... | LSP label x | IPv4 explicit NULL | Entropy lab= el | IPv4 payload | ...

=A0

There are probably other reserved labels that are ap= plicable as well.

=A0

In either case, the draft doesn't clearly state = what's supposed to happen. =A0If I follow the procedures in 4.3, the da= tapath would end up popping the GAL or the explicit NULL label (thinking th= ey are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous behaviour). = =A0 The only additional guidance that the draft gives is in section 6 where= it suggests that GAL could be treated as an application label. =A0But that= doesn't seem helpful since the LSP label must also be an application label (to handle the non-GAL case) and = will always be encountered first during label disposition. =A0Also, presuma= bly I don't want all GALs to expect entropy so there's an implied s= coping of GAL.

=A0

It seems to me that when a datapath encounters an en= tropy-enabled application label or an ELI, that it essentially must do a &q= uot;deferred pop of BOS label". =A0In other words, if the datapath enc= ounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels until it hits the BOS lab= el, which it must pop. =A0While certainly possible, this is a lot more conv= oluted and difficult to implement than what is specified in the draft. =A0I= s this really the desired behaviour?

=A0

The same question applies to type-4 VCCV with flow l= abels.

=A0

regards,

Pablo

=A0


This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


--e89a8fb1ffa49a52a604b9173ab8-- From rcallon@juniper.net Thu Feb 16 08:39: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 4981D21F87F8 for ; Thu, 16 Feb 2012 08:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 sc9dqiVwLJ+A for ; Thu, 16 Feb 2012 08:39:07 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 55A6621F87F1 for ; Thu, 16 Feb 2012 08:38:56 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0xH3AlHACikIzLNZf2iir3zEdJ/Qia@postini.com; Thu, 16 Feb 2012 08:39:07 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 08:37:40 -0800 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 08:37:39 -0800 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; Thu, 16 Feb 2012 11:37:38 -0500 From: Ross Callon To: "mpls@ietf.org" Date: Thu, 16 Feb 2012 11:37:37 -0500 Thread-Topic: Reminder with respect to IETF IPR rules Thread-Index: AQJdm+JsnidahE2I8QdWPQweCv1gsJUSHt/wgAAFPsCADB44sIAACrEA Message-ID: 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-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Reminder with respect to IETF IPR rules 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, 16 Feb 2012 16:39:10 -0000 All who participate in the IETF processes (whether by participating on IETF mailing lists, co-authoring documents, attending IETFs, or in other ways) n= eed to be aware of the IETF rules with regard to Intellectual Property Rights (= IPR). These rules are described in BCP79 and can be referenced through http://www.ietf.org/ipr/policy.html.=20 These are individual personal requirements that apply to all IETF participa= nts, including participants in the MPLS working group. =20 As MPLS WG chairs, we would like to minimize or hopefully eliminate late disclosures relating to MPLS WG documents. Because of this, you may see "reminder" emails in the future to authors and/or to the MPLS email list as= king people whether they know of IPR relating to specific documents. In order to comply with IETF processes while avoiding unnecessary delays, document auth= ors=20 and contributors and anyone who knows of any IPR related to MPLS documents = are=20 asked to take these emails seriously when they show up, and to respond in a= =20 timely fashion. However, these reminder emails are just that: only a remind= er=20 of existing IETF policy, and we are all bound by that policy even in the=20 absence of such reminder emails. =20 Thanks, Ross, Loa, and George (as MPLS WG co-chairs) From Alexander.Vainshtein@ecitele.com Thu Feb 16 10:21: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 0920C11E8074 for ; Thu, 16 Feb 2012 10:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.544 X-Spam-Level: X-Spam-Status: No, score=-4.544 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 jwDgBgB3tS+H for ; Thu, 16 Feb 2012 10:21:40 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 6A4C721F8634 for ; Thu, 16 Feb 2012 10:21:39 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1329416495!11847677!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 20460 invoked from network); 16 Feb 2012 18:21:36 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-8.tower-21.messagelabs.com with SMTP; 16 Feb 2012 18:21:36 -0000 X-AuditID: 93eaf2e7-b7f7e6d000000e6e-21-4f3d54f3fbf0 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 6A.E9.03694.3F45D3F4; Thu, 16 Feb 2012 21:11:47 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 16 Feb 2012 20:21:34 +0200 From: Alexander Vainshtein To: Pablo Frank Date: Thu, 16 Feb 2012 20:19:49 +0200 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: AczsxuMbq96bWAYQQmuyXUacvdqK9wADhOgx Message-ID: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> , 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_A3C5DF08D38B6049839A6F553B331C76011659266625ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLsWRmVeSWpSXmKPExsUy+dWnL7qfQ2z9DU7tU7CYc9fZ4tbSlawW 018fZ7Po+7SFxYHFY+esu+weS5b8ZPK43nSVPYA5qoHRJjEvL78ksSRVISW1ONlWKaAosywx uVJJITPFVslQSaEgJzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++ta WJha6hoq2akpGxpbc4VkZBYrpOrmJmbmKOSmFhcnpqcqAEUStjBnHLu0g7Wgfz9jxc63G5gb GH/PZ+xi5OSQEDCR+L/7NBuELSZx4d56IJuLQ0hgL6PE5v+rWCGcKYwSfR++M4NUsQnYSmxa fResQ0RATWLdxJlgk5gFMiWeLP/OBGKzCKhK/D7cDGRzcAgLmEssm1wPUW4hseDuLWYI20ji d+cEMJtXIFCi5+Q3FhBbSOAZk8TrRY4gNidQ/Of8JWBxRqDjvp9awwSxSlzi1pP5TBBHC0gs 2XOeGcIWlXj5+B8rRL2oxJ329VCn5Uu8ePiEEWKXoMTJmU9YIOolJQ6uuMEygVFsFpKxs5C0 zELSAhE3kHh/bj4zhK0tsWzhayhbX2Ljl7OMyOILGNlXMYpm5hSUJOWmGxjqpSZnlqTmpOol 5+duYoSkpec7GH/NVznEKMDBqMTDW2Bv6y/EmlhWXJl7iFGSg0lJlHeWO1CILyk/pTIjsTgj vqg0J7X4EKMEB7OSCG++DFCONyWxsiq1KB8m5QoM/InMUtzJ+cBUm1cSb2xggJujJM77NPmN r5BAOjBtZqemFqQWwcyR4eBQkuAN9gBaIViUmp5akZaZU4KQZuLgBDmDB+iMKJAa3uKCxNzi zHSI/ClGXY5pH55fYBRiycvPS5US560BKRIAKcoozYObA8pR9f///3/FKA4MAGHeKpAqHmB+ g5v0CmgJE9AS8xdWIEuAeQguJdXAuEo1J3UP11pj/9uXLRXftiu3L3vQfLv2ieXR89d2BC4/ GKolFtjjPytsR5G56RuPzTvbut1nOLT1HudsYXt2sITdvpjfdqnFrf5WdaYYI43VIc59ay+I XZjvcSxO+OBm8dkxKQt/XBeIZ9ObOilDesm3x/Lnu/VszIqr0sWuVG75fevmpusblFiKMxIN tZiLihMB9XgS9SwEAAA= Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Question about Entropy labels + GAL 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, 16 Feb 2012 18:21:42 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011659266625ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Pablo, Lots of thanks for a prompt response. I think that the situation with GAL between the PW (application label) and f= low label is much simpler than what you have described. This logic is based= on the fact "application labels" can be easily recognized as such by the LS= R that examines them during label stack parsing. When an application label is encountered, there are just three cases: 1. It is BoS - nothing new, pass to the corresponding application (PW forw= arder, VRF etc.) for handling. The data for this application directly follow= s the label stack (may include CW in the case of PW or VPLS) 2. Not BoS and the next label is GAL - stop parsing and pass to the "VCCV-= 4" handler, The data for the "VCCV-4 handler" application directly follows t= he label stack and starts with the ACH header. 3. Not BoS and the next label is not GAL - treat the next label as the "fl= ow label", i.e. pass to the corresponding application (may include CW in the= case of PW or VPLS). In the case of MS-PWs, only T-PEs would treat the PW labels as "application= labels", S-PEs would treat them as non-application labels. This is fully co= nsistent with RFC 6073 which explains that if you want an S-PE to handle a V= CCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined with= VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4. In other words, there is no need for ELI with the flow label. Did I miss something? My 2c, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Thursday, February 16, 2012 6:22 PM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Thanks Sasha. I completely concur with your points 1 and 2. As for point #3, that seems like the logical conclusion. However, I think t= here's still a bit of awkwardness around implementing this. Both the origin= al entropy-label draft and RFC 6391 have assumed a simple pop-pop logic when= you encounter an entropy-enabled AL or a flow-enabled PW. The moment GAL,= or any other reserved label gets thrown into the mix, the label disposition= logic gets suddenly more complex. Instead of pop-pop, the hardware will ha= ve to do more complicated logic like "IF this is a flow-enabled label AND th= e next label is ! GAL THEN pop-pop ELSE IF ..., etc.". While I have very pr= ogrammable hardware at my disposal, I prefer elegant and simple and this fee= ls wrong. It sounds like the authors of the entropy label draft have recognized this p= roblem and are now moving towards mandating the use of a reserved ELI which= unambiguously implies that the next label is entropy (so the hardware can g= o back to having simple pop-pop logic when it sees a reserved ELI). Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the situation i= s unambiguous. If I encounter any of these types of PWEs with flow-enabled,= I can do a pop-pop. If for type-4 VCCV, we assume that the GAL is between= the PW label and flow label (which I think was the intent), we're back to h= aving ugly logic to try and dispose of the GAL and flow label correctly. A= reserved ELI could help disambiguate the situation in this case but this ma= kes running type-4 VCCV with flow labels unattractive compared to type-1 VCC= V. regards, Pablo On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein > wrote: Pablo, John and all, A couple of comments: 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 has re= laxed the original requirement for GAL being at the bottom of stack that hav= e been defined in RFC 5586. 2. My reading of RFC 6391 is that it mandates the flow label to be at the= bottom of the label stack for PW packets carrying user data. And it does no= t provide for ELI usage anywhere, be it a reserved label or a signaled one. 3. To the best of my understanding, the situation when GAL is used for fat= PWs is not explicitly defined. Inserting GAL between the PW label and flow= label (with the ACH header immediately following the label stack) seems to= be fully compatible with both RFC 6423 and RFC 6391. Maybe this format shou= ld be explicitly defined as the correct one? Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf= .org] On Behalf Of Pablo Frank [pabloisnot@gma= il.com] Sent: Thursday, February 16, 2012 12:24 AM To: John E Drake Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat pse= udowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs when= flow labels are present? That seems too bad since the main advantage of ty= pe-4 VCCV seems to be to save a few bytes on the wire. This puts the overhe= ad right back in so it may be more attractive to run fat PWEs with type-1 VC= CV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake > wrote: Pablo, Based upon Kireeti=92s update in Taipei, we seem to going towards using a re= served label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-bounc= es@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question about= draft-ietf-mpls-entropy-label-01. Consider a scenario where I have receive= d the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is unn= ecessary. Following the procedures detailed in 4.3, the datapath would look= up label x and see that it is expecting a possible entropy label and since x= is not BOS, it pops the next label and then begins processing the IPv4 payl= oad. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the GA= L or the explicit NULL label (thinking they are entropy labels) and would th= en attempt to lookup the entropy label (which would result in erroneous beha= viour). The only additional guidance that the draft gives is in section 6= where it suggests that GAL could be treated as an application label. But t= hat doesn't seem helpful since the LSP label must also be an application lab= el (to handle the non-GAL case) and will always be encountered first during= label disposition. Also, presumably I don't want all GALs to expect entrop= y so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicatio= n label or an ELI, that it essentially must do a "deferred pop of BOS label"= . In other words, if the datapath encounters an entropy-enabled AL or an EL= I, it must make a note of it and continue processing labels until it hits th= e BOS label, which it must pop. While certainly possible, this is a lot mor= e convoluted and difficult to implement than what is specified in the draft.= Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76011659266625ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
Pablo,
Lots of thanks for a prompt response.
 
I think that the situation with GAL betw= een the PW (application label) and flow label is much simpler than what you= have described. This logic is based on the fact "application labels&qu= ot; can be easily recognized as such by the LSR that examines them during label stack parsing.
 
When an application label is encountered= , there are just three cases:
  1. It is BoS - nothing ne= w, pass to the corresponding application (PW forwarder, V= RF etc.) for handling. The data for this application directly follows= the label stack (may include CW in the case of PW or VPLS)
  2. Not BoS<= a> and the next label is GAL - stop parsing and pass to the "= ;VCCV-4" handler, The data for the "VCCV-4 handler" applicati= on directly follows the label stack and starts with the ACH header.
  3. Not BoS and the n= ext label is not GAL - treat the next label as the "flow label", i= .e. pass to the corresponding application (may include CW in the= case of PW or VPLS).

In the case of MS-PWs, only T-PEs would tr= eat the PW labels as "application labels", S-PEs would treat them= as non-application labels. This is fully consistent with RFC 6073 which exp= lains that if you want an S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined wi= th VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.

 

In other words, there is no need for ELI w= ith the flow label.

 

Did I miss something?

 

My 2c,

Sasha

 

From: Pablo Frank [pabloisnot@gmail.com]
Sent: Thursday, February 16, 2012 6:22 PM
To: Alexander Vainshtein
Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] Question about Entropy labels += GAL

Thanks Sasha.  I completely concur with your points 1 and 2.

As for point #3, that seems like the logical conclusion.  However,= I think there's still a bit of awkwardness around implementing this.  = Both the original entropy-label draft and RFC 6391 have assumed a simple pop= -pop logic when you encounter an entropy-enabled AL or a flow-enabled PW.  The moment GAL, or any other reserved label= gets thrown into the mix, the label disposition logic gets suddenly more co= mplex.  Instead of pop-pop, the hardware will have to do more complicat= ed logic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". &nb= sp;While I have very programmable hardware at my disposal, I prefer elegant= and simple and this feels wrong.

It sounds like the authors of the entropy label draft have recognized t= his problem and are now moving towards mandating the use of a reserved ELI w= hich unambiguously implies that the next label is entropy (so the hardware c= an go back to having simple pop-pop logic when it sees a reserved ELI).

Which brings me back to VCCV.  If I'm doing type-1,2,3 VCCV, the s= ituation is unambiguous.  If I encounter any of these types of PWEs wit= h flow-enabled, I can do a pop-pop.  If for type-4 VCCV, we assume that= the GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try and= dispose of the GAL and flow label correctly.  A reserved ELI could hel= p disambiguate the situation in this case but this makes running type-4 VCCV= with flow labels unattractive compared to type-1 VCCV.

regards,
Pablo

On Thu, Feb 16, 2012 at 1:22 AM, Alexander V= ainshtein <Al= exander.Vainshtein@ecitele.com> wrote:
Pablo, John and all,
A couple of comments:
 
  1. Following a long discussion on the PWE3 WG mailing list RFC 6423 ha= s relaxed the original requirement for GAL being at the bottom o= f stack that have been defined in RFC 5586.
  2. My reading of RFC 6391 is that it mandates the flow label to b= e at the bottom of the label stack for PW packets carrying user= data. And it does not provide for ELI usage anywhere, be it a reserved labe= l or a signaled one.
  3. To the best of my understanding, the situation when GAL is used for= fat PWs is not explicitly defined. Inserting GAL between the PW label= and flow label (with the ACH header immediately following the label stack)= seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the co= rrect one?

Regards,

     Sasha

 

 
 
 
 
 
 
 
From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo F= rank [pabloisnot@gmail.com]
Sent: Thursday, February 16, 2012 12:24 AM
To: John E Drake
Cc: mpls@ietf.org;= pwe3@ietf.org
Subject: Re: [mpls] Question about Entropy labels += GAL

Ah, good.  That certainly makes things more deterministic.  

I guess the question now becomes how will this affect type-4 VCCV on fa= t pseudowires (RFC 6391)?  Will type-4 VCCV have to= mandate the use of ELIs when flow labels are present?  That seems too= bad since the main advantage of type-4 VCCV seems to be to save a few bytes on the wire.  This puts the overhead right b= ack in so it may be more attractive to run fat PWEs with type-1 VCCV...

Pablo

On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.net> wrote:

Pablo,

 

Based upon Kireeti=92s up= date in Taipei, we seem to going towards using a reserved label for ELI and= making it always required.

 

Thanks,

 

John  

 

From: mpl= s-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: mpls@ietf.org<= br> Subject: [mpls] Question about Entropy labels + GAL=

 

I'm working on implementation for entropy labels and= I have a question about draft-ietf-mpls-entropy-label-01.  Consid= er a scenario where I have received the following:

 

... | LSP label x | Entropy label | IPv4 payload | ..= .

 

Assume that I've signaled that the LSP label wants en= tropy and an ELI is unnecessary.  Following the procedures detailed in= 4.3, the datapath would lookup label x and see that it i= s expecting a possible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 pa= yload.  So far, so good.  

 

However, I believe the following is legal as well:=

 

... | LSP label x | GAL label | Entropy label | BFD p= ayload | ...

 

Alternatively, an equally vexing scenario is:<= u>

 

... | LSP label x | IPv4 explicit NULL | Entropy labe= l | IPv4 payload | ...

 

There are probably other reserved labels that are app= licable as well.

 

In either case, the draft doesn't clearly state what'= s supposed to happen.  If I follow the procedures in 4.3, the data= path would end up popping the GAL or the explicit NULL label (= thinking they are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous b= ehaviour).   The only additional guidance that the draft= gives is in section 6 where it suggests that GAL could be treated as an app= lication label.  But that doesn't seem helpful since the LSP label must also be an application label (to ha= ndle the non-GAL case) and will always be encountered first during label dis= position.  Also, presumably I don't want all GALs to expect entropy so= there's an implied scoping of GAL.

 

It seems to me that when a datapath encounters an entropy-enabled application label or an ELI, that it essenti= ally must do a "deferred pop of BOS label".  In other words,= if the datapath encounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels unti= l it hits the BOS label, which it must pop.  While certainly possible,= this is a lot more convoluted and difficult to implement than what is speci= fied in the draft.  Is this really the desired behaviour?

 

The same question applies to type-4 VCCV with flow la= bels.

 

regards,

Pablo

 


This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76011659266625ILPTMAIL02e_-- From rcallon@juniper.net Thu Feb 16 10: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 94D8521F85A0 for ; Thu, 16 Feb 2012 10:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Ajre5alI4uOm for ; Thu, 16 Feb 2012 10:57:57 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5900721E8051 for ; Thu, 16 Feb 2012 10:57:51 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTz1RrmIHdrriyOLxTQvKz3uyom97/6/t@postini.com; Thu, 16 Feb 2012 10:57:51 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 10:56:21 -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; Thu, 16 Feb 2012 13:56:22 -0500 From: Ross Callon To: "'mpls@ietf.org'" Date: Thu, 16 Feb 2012 13:56:20 -0500 Thread-Topic: draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB Thread-Index: Acx3zaP9pBvz5QrkRo6DwIhB+Her7B1DV+vg Message-ID: References: <7AFCB34F348315478447EDD041C28DDF9C07426F10@EMBX01-WF.jnpr.net> In-Reply-To: <7AFCB34F348315478447EDD041C28DDF9C07426F10@EMBX01-WF.jnpr.net> 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_DF7F294AF4153D498141CBEFADB17704C70B619627EMBX01WFjnprn_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB 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, 16 Feb 2012 18:57:59 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C70B619627EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My apologies for the excessive delay in dealing with the issue of whether t= he authors can be permitted to resubmit draft-ietf-mpls-tp-te-mib as a read= -only MIB. In looking through the replies to the WG last call, there were very few rep= lies and no clear WG consensus. As such it would be wrong in my opinion to = compel the authors to do something that they don't want to do. As such the = authors of draft-ietf-mpls-tp-te-mib will be permitted to resubmit the draf= t as a read-only MIB if that is there preference. Naturally as the document continues to progress as a working group document= any participant in the working group is free to comment on the document (o= r any other WG document) and to propose changes (whether major or minor). I= f there is WG consensus for such changes then they will be made. Thanks, Ross (as WG co-chair) _____________________________________________ From: Ross Callon Sent: Tuesday, September 20, 2011 3:44 PM To: mpls@ietf.org Subject: draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB= (it currently contains relatively few writeable objects). This is compatib= le with my understanding of how MIBs are often used. However, this also var= ies from normal IETF convention where MIBs contain both read and write obje= cts. We therefore are asking for comments from the WG regarding whether people a= re okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only. Thanks, Ross (for the MPLS WG co-chairs) --_000_DF7F294AF4153D498141CBEFADB17704C70B619627EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My apologies for the excessive delay in dealin= g with the issue of whether the authors can be permitted to resubmit draft-= ietf-mpls-tp-te-mib as a read-only MIB.
 
In looking through the replies to the WG last = call, there were very few replies and no clear WG consensus. As such it wou= ld be wrong in my opinion to compel the authors to do something that they d= on’t want to do. As such the authors of draft-ietf-mpls-tp-te-mib will be permitted to resubmit the draft as a r= ead-only MIB if that is there preference.
 
Naturally as the document continues to progres= s as a working group document any participant in the working group is free = to comment on the document (or any other WG document) and to propose change= s (whether major or minor). If there is WG consensus for such changes then they will be made.
 
Thanks, Ross
(as WG co-chair)
 
_________________________= ____________________
From: Ross Callon
Sent: Tuesday, September 20, 2011 3:44 PM
To: mpls@ietf.org
Subject: draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB
 
 
There is a plan to make draft-ietf-= mpls-tp-te-mib-00.txt be a read-only MIB (it currently contains relatively = few writeable objects). This is compatible with my understanding of how MIB= s are often used. However, this also varies from normal IETF convention where MIBs contain both read and write o= bjects.
 
We therefore are asking for comment= s from the WG regarding whether people are okay with updating draft-ietf-mp= ls-tp-te-mib-00.txt to be read only.
 
Thanks, Ross
(for the MPLS WG co-chairs) =
 
 --_000_DF7F294AF4153D498141CBEFADB17704C70B619627EMBX01WFjnprn_-- From tnadeau@lucidvision.com Thu Feb 16 11:46: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 A80B821E8077 for ; Thu, 16 Feb 2012 11:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.073, 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 Ma5dqtOAP7Lj for ; Thu, 16 Feb 2012 11:46:13 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5916021E807D for ; Thu, 16 Feb 2012 11:46:13 -0800 (PST) Received: from [10.100.68.86] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id B99B9208E5D3; Thu, 16 Feb 2012 14:46:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_DFBC5F5A-A1C9-40C6-9FF5-8C734FF19E28" From: Thomas Nadeau In-Reply-To: Date: Thu, 16 Feb 2012 14:46:12 -0500 Message-Id: References: <7AFCB34F348315478447EDD041C28DDF9C07426F10@EMBX01-WF.jnpr.net> To: Ross Callon X-Mailer: Apple Mail (2.1257) Cc: "'mpls@ietf.org'" Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB 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, 16 Feb 2012 19:46:17 -0000 --Apple-Mail=_DFBC5F5A-A1C9-40C6-9FF5-8C734FF19E28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the clarification. It is definitely our preference to = do read-only. We will modify the draft in a future revision to make it = read-only. --Tom > My apologies for the excessive delay in dealing with the issue of = whether the authors can be permitted to resubmit = draft-ietf-mpls-tp-te-mib as a read-only MIB. > =20 > In looking through the replies to the WG last call, there were very = few replies and no clear WG consensus. As such it would be wrong in my = opinion to compel the authors to do something that they don=92t want to = do. As such the authors of draft-ietf-mpls-tp-te-mib will be permitted = to resubmit the draft as a read-only MIB if that is there preference. > =20 > Naturally as the document continues to progress as a working group = document any participant in the working group is free to comment on the = document (or any other WG document) and to propose changes (whether = major or minor). If there is WG consensus for such changes then they = will be made. > =20 > Thanks, Ross > (as WG co-chair) > =20 > _____________________________________________ > From: Ross Callon=20 > Sent: Tuesday, September 20, 2011 3:44 PM > To: mpls@ietf.org > Subject: draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB > =20 > =20 > There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a = read-only MIB (it currently contains relatively few writeable objects). = This is compatible with my understanding of how MIBs are often used. = However, this also varies from normal IETF convention where MIBs contain = both read and write objects. > =20 > We therefore are asking for comments from the WG regarding whether = people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be = read only. > =20 > Thanks, Ross > (for the MPLS WG co-chairs) > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_DFBC5F5A-A1C9-40C6-9FF5-8C734FF19E28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Thanks for the clarification. It = is definitely our preference to do read-only. We will modify the draft = in a future revision to make it = read-only.

= --Tom


My = apologies for the excessive delay in dealing with the issue of whether = the authors can be permitted to resubmit draft-ietf-mpls-tp-te-mib as a = read-only MIB.
 
In = looking through the replies to the WG last call, there were very few = replies and no clear WG consensus. As such it would be wrong in my = opinion to compel the authors to do something that they don=92t want to = do. As such the authors of draft-ietf-mpls-tp-te-mib will be permitted = to resubmit the draft as a read-only MIB if that is there = preference.
 
Naturally as the document continues to progress as a = working group document any participant in the working group is free to = comment on the document (or any other WG document) and to propose = changes (whether major or minor). If there is WG consensus for such = changes then they will be made.
 
Thanks, Ross
(as WG co-chair)
 
_____________________________________________
From: Ross Callon 
Sent: Tuesday, September 20, 2011 = 3:44 PM
To: mpls@ietf.org
Subject: draft-ietf-mpls-tp-te-mib = Consensus Call on Read-Only MIB
 
 
There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be = a read-only MIB (it currently contains relatively few writeable = objects). This is compatible with my understanding of how MIBs are often = used. However, this also varies from normal IETF convention where MIBs = contain both read and write objects.
 
We therefore are asking for comments from = the WG regarding whether people are okay with updating = draft-ietf-mpls-tp-te-mib-00.txt to be read only.
 
Thanks, Ross
(for the MPLS WG = co-chairs)
 
____________________________________= ___________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

= --Apple-Mail=_DFBC5F5A-A1C9-40C6-9FF5-8C734FF19E28-- From pranjal.dutta@alcatel-lucent.com Thu Feb 16 17:31: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 B4BD621E809B for ; Thu, 16 Feb 2012 17:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 bnEt38Avi-xJ for ; Thu, 16 Feb 2012 17:31:39 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 75E6921E8099 for ; Thu, 16 Feb 2012 17:31:39 -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 q1H1VPmG023617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Feb 2012 19:31:27 -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 q1H1VN4o014234 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Feb 2012 07:01: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; Fri, 17 Feb 2012 07:01:23 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "mtinka@globaltransit.net" , "mpls@ietf.org" Date: Fri, 17 Feb 2012 07:01:21 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Aczon+i0Uh7XDsyZRpWsJQJAXcYzXgEc25AA Message-ID: References: <201202111730.03501.mtinka@globaltransit.net> In-Reply-To: <201202111730.03501.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\)" 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, 17 Feb 2012 01:31:46 -0000 I think we are confusing separate ldp hello adjacencies with fate separatio= n. I would be a bit more explicit. Having separate hello adjacencies for IP= V4 and IPV6 but same ldp session DOES NOT yield fate separation. Fate separ= ation would require two || ldp sessions between peers. What we raised is th= at - the separate hello adjacencies for ipv4 and ipv6 as per Ldp-ipv6 draft= does not make any sense since we can do away with single=20 adjacency with per adjacency capabilities. Fate separation is a different=20 Problem which can be addressed by multi-lsr sessions between two peering=20 Systems. Thanks, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mar= k Tinka Sent: Saturday, February 11, 2012 1:30 AM To: mpls@ietf.org Cc: Aissaoui, Mustapha (Mustapha) Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 On Tuesday, February 07, 2012 04:44:58 AM Phil Bedard wrote: > I understand the road LDP has gone down with regards to > using a single session/adjacency to advertise multiple > families of FECs, similar to BGP. Like I said, many > providers these days have taken steps to separate their > IPv6 and IPv4 control planes, usually for shared-fate > concerns with software defects and to just keep things > simpler for operational folks to deal with (which is > somewhat debatable). As an operator, I have to agree with Phil as well. Operators will expect that LDPv4 and LDPv6 will likely be=20 different adjacencies, with independent FEC for each address=20 family, even though the capabilities being advertised by LDP=20 may be the same, but only activated based on whether those=20 capabilities are in operation for that particular address=20 family or not. At any rate, fate sharing would be undesireable for=20 operators. Moreover, I'd prefer that if operators have=20 choice in how LDP would operate, independence of adjacencies=20 and FEC's be the default, and a combination be optional. > Mustapha mentioned BGP but the fact is providers today > use two different sessions to adveritse v4 vs. v6 NLRI, > regardless of the capabilities for either to advertise > both NLRI. This is very true. In dual-stack systems, we (and a number of other operators)=20 will have separate but similar deployments between IPv4 and=20 IPv6 protocols. IS-IS is just about the only exception, but=20 while the protocol integrates support for both IPv4 and=20 IPv6, we still consider the operation of adjacencies=20 separate on the wire. Mark. From pabloisnot@gmail.com Fri Feb 17 08:39: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 B89A621F8847; Fri, 17 Feb 2012 08:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.265, 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 GZyR0c0KiZTa; Fri, 17 Feb 2012 08:39:40 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98BC021F87A3; Fri, 17 Feb 2012 08:39:40 -0800 (PST) Received: by ggnq2 with SMTP id q2so2167712ggn.31 for ; Fri, 17 Feb 2012 08:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vhX/MZZvvSciaqLgikLP71a1wF1ssj8yzCvzcLA4FIU=; b=Ut5MuFYJyXa2nILk3zlSczHGS4CGa6bd5zDx5bW4dpeYMo0Ua3lZoWJt+oNDxO+o+3 lETQ27b1rVhNIT07l0q8HHEszzeSrjFJMCaQ1RJ/KhuH5twJVXXup1IEUW8qT6a2mmF/ 9ajLOvUN0a7b/SGyWOCVntWH6pGPIBWpilBX4= MIME-Version: 1.0 Received: by 10.60.13.129 with SMTP id h1mr2683282oec.62.1329496780159; Fri, 17 Feb 2012 08:39:40 -0800 (PST) Received: by 10.182.42.137 with HTTP; Fri, 17 Feb 2012 08:39:40 -0800 (PST) In-Reply-To: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> Date: Fri, 17 Feb 2012 11:39:40 -0500 Message-ID: From: Pablo Frank To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=e89a8f8397674fbb2004b92b97ed Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Question about Entropy labels + GAL 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, 17 Feb 2012 16:39:42 -0000 --e89a8f8397674fbb2004b92b97ed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sasha, Even the relatively simple set of rules that you've defined below glosses over a some added complexity in trying to do a hardware implementation. I think we can at least agree that this is not nearly as simple as using reserved ELI (which a dumb parser can dispose of without needing to even look anything up). I guess I'm just nervous about the lookup context of a label affecting the disposition of a label that is not necessarily next in the stack. To me this feels like a slippery slope. What if, in the future, we come up with more "stuff" that goes between the AL and the EL? The permutations quickly multiply and this will ultimately impact the cost of hardware. Just something to keep in mind as we go forward. In any case, I think there's enough uncertainty that the authors of type-4 VCCV should probably explicitly address how they expect it to interact with flow labels. Pablo On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Pablo, > Lots of thanks for a prompt response. > > I think that the situation with GAL between the PW (application label) an= d > flow label is much simpler than what you have described. This logic is > based on the fact "application labels" can be easily recognized as such b= y > the LSR that examines them during label stack parsing. > > When an application label is encountered, there are just three cases: > > 1. It is BoS - nothing new, pass to the corresponding application (PW > forwarder, VRF etc.) for handling. The data for this application > directly follows the label stack (may include CW in the case of PW or = VPLS) > 2. Not BoS and the next label is GAL - stop parsing and pass to the > "VCCV-4" handler, The data for the "VCCV-4 handler" application direct= ly > follows the label stack and starts with the ACH header. > 3. Not BoS and the next label is not GAL - treat the next label as the > "flow label", i.e. pass to the corresponding application (may include > CW in the case of PW or VPLS). > > In the case of MS-PWs, only T-PEs would treat the PW labels as > "application labels", S-PEs would treat them as non-application labels. > This is fully consistent with RFC 6073 which explains that if you want an > S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) > possibly combined with VCCV Type 1 (if the PWE has been using a CW) or VC= CV > Type 4. > > > > In other words, there is no need for ELI with the flow label. > > > > Did I miss something? > > > > My 2c, > > Sasha > > > ------------------------------ > *From:* Pablo Frank [pabloisnot@gmail.com] > *Sent:* Thursday, February 16, 2012 6:22 PM > *To:* Alexander Vainshtein > *Cc:* John E Drake; mpls@ietf.org; pwe3@ietf.org > > *Subject:* Re: [mpls] Question about Entropy labels + GAL > > Thanks Sasha. I completely concur with your points 1 and 2. > > As for point #3, that seems like the logical conclusion. However, I > think there's still a bit of awkwardness around implementing this. Both > the original entropy-label draft and RFC 6391 have assumed a simple pop-p= op > logic when you encounter an entropy-enabled AL or a flow-enabled PW. The > moment GAL, or any other reserved label gets thrown into the mix, the lab= el > disposition logic gets suddenly more complex. Instead of pop-pop, the > hardware will have to do more complicated logic like "IF this is a > flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., > etc.". While I have very programmable hardware at my disposal, I prefer > elegant and simple and this feels wrong. > > It sounds like the authors of the entropy label draft have recognized > this problem and are now moving towards mandating the use of a reserved E= LI > which unambiguously implies that the next label is entropy (so the hardwa= re > can go back to having simple pop-pop logic when it sees a reserved ELI). > > Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the > situation is unambiguous. If I encounter any of these types of PWEs with > flow-enabled, I can do a pop-pop. If for type-4 VCCV, we assume that the > GAL is between the PW label and flow label (which I think was the intent)= , > we're back to having ugly logic to try and dispose of the GAL and flow > label correctly. A reserved ELI could help disambiguate the situation in > this case but this makes running type-4 VCCV with flow labels unattractiv= e > compared to type-1 VCCV. > > regards, > Pablo > > On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote: > >> Pablo, John and all, >> A couple of comments: >> >> >> 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 >> has relaxed the original requirement for GAL being at the bottom of >> stack that have been defined in RFC 5586. >> 2. My reading of RFC 6391 is that it mandates the flow label to be at >> the bottom of the label stack for PW packets carrying user data. And >> it does not provide for ELI usage anywhere, be it a reserved label or= a >> signaled one. >> 3. To the best of my understanding, the situation when GAL is used >> for fat PWs is not explicitly defined. Inserting GAL between the PW l= abel >> and flow label (with the ACH header immediately following the label s= tack) >> seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe t= his >> format should be explicitly defined as the correct one? >> >> Regards, >> >> Sasha >> >> >> >> >> >> >> >> >> >> ------------------------------ >> *From:* mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo >> Frank [pabloisnot@gmail.com] >> *Sent:* Thursday, February 16, 2012 12:24 AM >> *To:* John E Drake >> *Cc:* mpls@ietf.org; pwe3@ietf.org >> *Subject:* Re: [mpls] Question about Entropy labels + GAL >> >> Ah, good. That certainly makes things more deterministic. >> >> I guess the question now becomes how will this affect type-4 VCCV on >> fat pseudowires (RFC 6391)? Will type-4 VCCV have to mandate the use of >> ELIs when flow labels are present? That seems too bad since the main >> advantage of type-4 VCCV seems to be to save a few bytes on the wire. T= his >> puts the overhead right back in so it may be more attractive to run fat >> PWEs with type-1 VCCV... >> >> Pablo >> >> On Wed, Feb 15, 2012 at 4:26 PM, John E Drake wrote= : >> >>> Pablo,**** >>> >>> **** >>> >>> Based upon Kireeti=92s update in Taipei, we seem to going towards using= a >>> reserved label for ELI and making it always required.**** >>> >>> **** >>> >>> Thanks,**** >>> >>> **** >>> >>> John **** >>> >>> **** >>> >>> *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf >>> Of *Pablo Frank >>> *Sent:* Wednesday, February 15, 2012 7:30 AM >>> *To:* mpls@ietf.org >>> *Subject:* [mpls] Question about Entropy labels + GAL**** >>> >>> **** >>> >>> I'm working on implementation for entropy labels and I have a question >>> about draft-ietf-mpls-entropy-label-01. Consider a scenario where I ha= ve >>> received the following:**** >>> >>> **** >>> >>> ... | LSP label x | Entropy label | IPv4 payload | ...**** >>> >>> **** >>> >>> Assume that I've signaled that the LSP label wants entropy and an ELI i= s >>> unnecessary. Following the procedures detailed in 4.3, the datapathwou= ld lookup label x and see that it is expecting a possible entropy label >>> and since x is not BOS, it pops the next label and then begins processi= ng >>> the IPv4 payload. So far, so good. **** >>> >>> **** >>> >>> However, I believe the following is legal as well:**** >>> >>> **** >>> >>> ... | LSP label x | GAL label | Entropy label | BFD payload | ...**** >>> >>> **** >>> >>> Alternatively, an equally vexing scenario is:**** >>> >>> **** >>> >>> ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | >>> ...**** >>> >>> **** >>> >>> There are probably other reserved labels that are applicable as well.**= * >>> * >>> >>> **** >>> >>> In either case, the draft doesn't clearly state what's supposed to >>> happen. If I follow the procedures in 4.3, the datapath would end up >>> popping the GAL or the explicit NULL label (thinking they are entropy >>> labels) and would then attempt to lookup the entropy label (which would >>> result in erroneous behaviour). The only additional guidance that the >>> draft gives is in section 6 where it suggests that GAL could be treated= as >>> an application label. But that doesn't seem helpful since the LSP labe= l >>> must *also *be an application label (to handle the non-GAL case) and >>> will always be encountered first during label disposition. Also, >>> presumably I don't want all GALs to expect entropy so there's an implie= d >>> scoping of GAL.**** >>> >>> **** >>> >>> It seems to me that when a datapath encounters an entropy-enabled >>> application label or an ELI, that it essentially must do a "deferred po= p of >>> BOS label". In other words, if the datapath encounters an >>> entropy-enabled AL or an ELI, it must make a note of it and continue >>> processing labels until it hits the BOS label, which it must pop. Whil= e >>> certainly possible, this is a lot more convoluted and difficult to >>> implement than what is specified in the draft. Is this really the desi= red >>> behaviour?**** >>> >>> **** >>> >>> The same question applies to type-4 VCCV with flow labels.**** >>> >>> **** >>> >>> regards,**** >>> >>> Pablo**** >>> >>> **** >>> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --e89a8f8397674fbb2004b92b97ed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sasha,

Even the relatively simple set of rules that y= ou've defined below glosses over a some added complexity in trying to d= o a hardware implementation. =A0I think we can at least agree that this is = not nearly as simple as using reserved ELI (which a dumb parser can dispose= of without needing to even look anything up). =A0I guess I'm just nerv= ous about the lookup context of a label affecting the disposition of a labe= l that is not necessarily next in the stack. =A0To me this feels like a sli= ppery slope. =A0What if, in the future, we come up with more "stuff&qu= ot; that goes between the AL and the EL? =A0The permutations quickly multip= ly and this will ultimately impact the cost of hardware.

Just something to keep in mind as we go forward.
<= div>
In any case, I think there's enough uncertainty that= the authors of type-4 VCCV should probably explicitly address how they exp= ect it to interact with flow labels.

Pablo

On Thu, Feb 16,= 2012 at 1:19 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com&= gt; wrote:
Pablo,
Lots of thanks for a prompt response.
=A0
I think that the situation with GAL bet= ween the PW (application label) and flow label is much simpler than what yo= u have described. This logic is based on the fact "application labels&= quot; can be easily recognized as such by the LSR that examines them during label stack parsing.
=A0
When an application label is encountere= d, there are just three cases:
  1. It is=A0BoS - nothing new,= pass to the=A0corresponding application (PW forwarder, VRF e= tc.) for handling. The data for this application directly follows th= e label stack (may include CW in=A0the case of PW or VPLS)
  2. Not=A0BoS= and the next label is GAL - stop parsing and pass to the "= VCCV-4" handler, The data for the "VCCV-4 handler" applicati= on directly follows the label stack and starts with the ACH header.
  3. Not=A0BoS and the nex= t label is not GAL - treat the next label as the "flow label", i.= e. pass to the=A0corresponding application (may include CW in the ca= se of PW or VPLS).

In the case of MS-PWs, only T-PEs would t= reat the PW labels as "application labels", S-PEs would treat the= m as non-application labels. This is fully consistent with RFC 6073 which e= xplains that if you want an S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined w= ith VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.

=A0

In other words, there is no need for ELI = with the flow label.

=A0

Did I miss something?

=A0

My 2c,

Sasha

=A0

Fro= m: Pablo Frank [pabloisnot@gmail.com]
Sent: Thursday, February 16, 2012 6:22 PM
To: Alexander Vainshtein
Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org

Subject: Re: [mpls] Question about Entropy labels + GA= L

Thanks Sasha. =A0I completely concur with your points 1 and 2.

As for point #3, that seems like the logical conclusion. =A0However, I= think there's still a bit of awkwardness around implementing this. =A0= Both the original entropy-label draft and RFC 6391 have assumed a simple po= p-pop logic when you encounter an entropy-enabled AL or a flow-enabled PW. =A0The moment GAL, or any other reserved label ge= ts thrown into the mix, the label disposition logic gets suddenly more comp= lex. =A0Instead of pop-pop, the hardware will have to do more complicated l= ogic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". = =A0While I have very programmable hardware at my disposal, I prefer elegant= and simple and this feels wrong.

It sounds like the authors of the entropy label draft have recognized = this problem and are now moving towards mandating the use of a reserved ELI= which unambiguously implies that the next label is entropy (so the hardwar= e can go back to having simple pop-pop logic when it sees a reserved ELI).

Which brings me back to VCCV. =A0If I'm doing type-1,2,3 VCCV, the= situation is unambiguous. =A0If I encounter any of these types of PWEs wit= h flow-enabled, I can do a pop-pop. =A0If for type-4 VCCV, we assume that t= he GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try= and dispose of the GAL and flow label correctly. =A0A reserved ELI could h= elp disambiguate the situation in this case but this makes running type-4 V= CCV with flow labels unattractive compared to type-1 VCCV.

regards,
Pablo

On Thu, Feb 16, 2012 at 1:22 AM, Alexander=A0Vai= nshtein <Alexander.Vainshtein@ecitele.com> wrote:
Pablo, John and all,
A couple of comments:
=A0
  1. Following a=A0long discussion on the PWE3 WG mailing list RFC 6423 has = relaxed the original=A0requirement for GAL being at the bottom of st= ack that have been defined in RFC 5586.
  2. My reading of=A0RFC 6391 is that it mandates the flow label to be = at the bottom of the label stack for PW packets=A0carrying user data= . And it does not provide for ELI usage anywhere, be it a reserved label or= a signaled one.
  3. To the best of my understanding, the situation when GAL is used fo= r fat PWs is not explicitly defined.=A0Inserting GAL between the PW label a= nd flow label (with the ACH header immediately following the label stack) s= eems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the c= orrect one?

Regards,

=A0=A0=A0=A0 Sasha

=A0

=A0
=A0
=A0
=A0
=A0
=A0
From:=A0mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo Frank [pabloisnot@gmail.com]
Sent: Thursday, February 16, 2012 12:24 AM
To: John E Drake
Cc: mpls@ietf.org= ; pwe3@ietf.org
Subject: Re: [mpls] Question about Entropy labels + GA= L

Ah, good. =A0That certainly makes things more deterministic. =A0

I guess the question now becomes how will this affect type-4 VCCV on f= at=A0pseudowires (RFC 6391)? =A0Will type-4 VCCV have to mand= ate the use of ELIs when flow labels are present? =A0That seems too bad sin= ce the main advantage of type-4 VCCV seems to be to save a few bytes on the wire. =A0This puts the overhead right bac= k in so it may be more attractive to run fat PWEs with type-1 VCCV...

Pablo

On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.= net> wrote:

Pablo,

=A0

Based upon=A0Kireeti=92s= update in Taipei, we seem to going towards using a reserved label f= or ELI and making it always required.

=A0

Thanks,

=A0

John =A0

=A0

From:=A0mpls-bounces@ietf.org [mailto:mp= ls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: mpls@ietf.org=
Subject: [mpls] Question about Entropy labels + GAL=

=A0

I'm working on implementation for entropy labels= and I have a question about=A0draft-ietf-mpls-entropy-label-01. =A0Conside= r a scenario where I have received the following:

=A0

... | LSP label x | Entropy label | IPv4 payload | .= ..

=A0

Assume that I've signaled that the LSP label wan= ts entropy and an ELI is unnecessary. =A0Following the procedures detailed = in 4.3, the=A0datapath would lookup label x and see that it i= s expecting a possible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 p= ayload. =A0So far, so good. =A0

=A0

However, I believe the following is legal as well:

=A0

... | LSP label x | GAL label | Entropy label | BFD = payload | ...

=A0

Alternatively, an equally vexing scenario is:=

=A0

... | LSP label x | IPv4 explicit NULL | Entropy lab= el | IPv4 payload | ...

=A0

There are probably other reserved labels that are ap= plicable as well.

=A0

In either case, the draft doesn't clearly state = what's supposed to happen. =A0If I follow the procedures in 4.3, the=A0= datapath would end up popping the GAL or the explicit NULL la= bel (thinking they are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous = behaviour). =A0 The only additional guidance that the draft g= ives is in section 6 where it suggests that GAL could be treated as an appl= ication label. =A0But that doesn't seem helpful since the LSP label must also be an application label (to h= andle the non-GAL case) and will always be encountered first during label d= isposition. =A0Also, presumably I don't want all GALs to expect entropy= so there's an implied scoping of GAL.

=A0

It seems to me that when a=A0datapath = encounters an entropy-enabled application label or an ELI, that it essentia= lly must do a "deferred pop of BOS label". =A0In other words, if = the=A0datapath encounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels unt= il it hits the BOS label, which it must pop. =A0While certainly possible, t= his is a lot more convoluted and difficult to implement than what is specif= ied in the draft. =A0Is this really the desired behaviour?

=A0

The same question applies to type-4 VCCV with flow l= abels.

=A0

regards,

Pablo

=A0


This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.


This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


--e89a8f8397674fbb2004b92b97ed-- From loa@pi.nu Fri Feb 17 08:46: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 02A2E21E8039 for ; Fri, 17 Feb 2012 08:46:38 -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 S89p6pPXloVA for ; Fri, 17 Feb 2012 08:46:37 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id E535521E802B for ; Fri, 17 Feb 2012 08:46:35 -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 2567F2A8002; Fri, 17 Feb 2012 17:46:33 +0100 (CET) Message-ID: <4F3E8461.9070002@pi.nu> Date: Fri, 17 Feb 2012 17:46:25 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 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> In-Reply-To: <4F327811.1000700@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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, 17 Feb 2012 16:46:38 -0000 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 jdrake@juniper.net Fri Feb 17 09:17: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 C537721F856C; Fri, 17 Feb 2012 09:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.672 X-Spam-Level: X-Spam-Status: No, score=-4.672 tagged_above=-999 required=5 tests=[AWL=1.926, 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 SA396db830aA; Fri, 17 Feb 2012 09:17:34 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id E8C7821F8565; Fri, 17 Feb 2012 09:17:33 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTz6LqsrhBxKR4PLnnoFb3+Xx6II7KNJj@postini.com; Fri, 17 Feb 2012 09:17:34 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 17 Feb 2012 09:14:44 -0800 From: John E Drake To: Pablo Frank , Alexander Vainshtein Date: Fri, 17 Feb 2012 09:14:40 -0800 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: Acztkr/ZfcakB5fsRVC53QNq6RQsEQABBVdg Message-ID: <5E893DB832F57341992548CDBB333163A55C914900@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f8e27f27-03b2-4c3e-9447-119194e72cb6 Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A55C914900EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] Question about Entropy labels + GAL 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, 17 Feb 2012 17:17:40 -0000 --_000_5E893DB832F57341992548CDBB333163A55C914900EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pablo, These are some of the same conclusions to which the EL authors came. The d= eployment environment for FAT labels, pt-2-pt, is more constrained than the= deployment environment for ELs, any- 2-any, so presumably some of these ca= ses could be handled in signaling, such that both endpoints know what to ex= pect before packets start to flow. However, it might be nice to use a rese= rved ELI for FAT labels in order to have a consistent data plane for both. Thanks, John From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, February 17, 2012 8:40 AM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Hi Sasha, Even the relatively simple set of rules that you've defined below glosses o= ver a some added complexity in trying to do a hardware implementation. I t= hink we can at least agree that this is not nearly as simple as using reser= ved ELI (which a dumb parser can dispose of without needing to even look an= ything up). I guess I'm just nervous about the lookup context of a label a= ffecting the disposition of a label that is not necessarily next in the sta= ck. To me this feels like a slippery slope. What if, in the future, we co= me up with more "stuff" that goes between the AL and the EL? The permutati= ons quickly multiply and this will ultimately impact the cost of hardware. Just something to keep in mind as we go forward. In any case, I think there's enough uncertainty that the authors of type-4 = VCCV should probably explicitly address how they expect it to interact with= flow labels. Pablo On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainshtein > wrote: Pablo, Lots of thanks for a prompt response. I think that the situation with GAL between the PW (application label) and = flow label is much simpler than what you have described. This logic is base= d on the fact "application labels" can be easily recognized as such by the = LSR that examines them during label stack parsing. When an application label is encountered, there are just three cases: 1. It is BoS - nothing new, pass to the corresponding application (PW for= warder, VRF etc.) for handling. The data for this application directly foll= ows the label stack (may include CW in the case of PW or VPLS) 2. Not BoS and the next label is GAL - stop parsing and pass to the "VCCV= -4" handler, The data for the "VCCV-4 handler" application directly follows= the label stack and starts with the ACH header. 3. Not BoS and the next label is not GAL - treat the next label as the "f= low label", i.e. pass to the corresponding application (may include CW in t= he case of PW or VPLS). In the case of MS-PWs, only T-PEs would treat the PW labels as "application= labels", S-PEs would treat them as non-application labels. This is fully c= onsistent with RFC 6073 which explains that if you want an S-PE to handle a= VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined w= ith VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4. In other words, there is no need for ELI with the flow label. Did I miss something? My 2c, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Thursday, February 16, 2012 6:22 PM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Thanks Sasha. I completely concur with your points 1 and 2. As for point #3, that seems like the logical conclusion. However, I think = there's still a bit of awkwardness around implementing this. Both the orig= inal entropy-label draft and RFC 6391 have assumed a simple pop-pop logic w= hen you encounter an entropy-enabled AL or a flow-enabled PW. The moment G= AL, or any other reserved label gets thrown into the mix, the label disposi= tion logic gets suddenly more complex. Instead of pop-pop, the hardware wi= ll have to do more complicated logic like "IF this is a flow-enabled label = AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". While I have = very programmable hardware at my disposal, I prefer elegant and simple and = this feels wrong. It sounds like the authors of the entropy label draft have recognized this = problem and are now moving towards mandating the use of a reserved ELI whic= h unambiguously implies that the next label is entropy (so the hardware can= go back to having simple pop-pop logic when it sees a reserved ELI). Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the situation = is unambiguous. If I encounter any of these types of PWEs with flow-enable= d, I can do a pop-pop. If for type-4 VCCV, we assume that the GAL is betwe= en the PW label and flow label (which I think was the intent), we're back t= o having ugly logic to try and dispose of the GAL and flow label correctly.= A reserved ELI could help disambiguate the situation in this case but thi= s makes running type-4 VCCV with flow labels unattractive compared to type-= 1 VCCV. regards, Pablo On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein > wrote: Pablo, John and all, A couple of comments: 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 has r= elaxed the original requirement for GAL being at the bottom of stack that h= ave been defined in RFC 5586. 2. My reading of RFC 6391 is that it mandates the flow label to be at the= bottom of the label stack for PW packets carrying user data. And it does n= ot provide for ELI usage anywhere, be it a reserved label or a signaled one= . 3. To the best of my understanding, the situation when GAL is used for fa= t PWs is not explicitly defined. Inserting GAL between the PW label and flo= w label (with the ACH header immediately following the label stack) seems t= o be fully compatible with both RFC 6423 and RFC 6391. Maybe this format sh= ould be explicitly defined as the correct one? Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@iet= f.org] On Behalf Of Pablo Frank [pabloisnot@g= mail.com] Sent: Thursday, February 16, 2012 12:24 AM To: John E Drake Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat ps= eudowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs whe= n flow labels are present? That seems too bad since the main advantage of = type-4 VCCV seems to be to save a few bytes on the wire. This puts the ove= rhead right back in so it may be more attractive to run fat PWEs with type-= 1 VCCV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake > wrote: Pablo, Based upon Kireeti's update in Taipei, we seem to going towards using a res= erved label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question abou= t draft-ietf-mpls-entropy-label-01. Consider a scenario where I have recei= ved the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is un= necessary. Following the procedures detailed in 4.3, the datapath would lo= okup label x and see that it is expecting a possible entropy label and sinc= e x is not BOS, it pops the next label and then begins processing the IPv4 = payload. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the G= AL or the explicit NULL label (thinking they are entropy labels) and would = then attempt to lookup the entropy label (which would result in erroneous b= ehaviour). The only additional guidance that the draft gives is in sectio= n 6 where it suggests that GAL could be treated as an application label. B= ut that doesn't seem helpful since the LSP label must also be an applicatio= n label (to handle the non-GAL case) and will always be encountered first d= uring label disposition. Also, presumably I don't want all GALs to expect = entropy so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicati= on label or an ELI, that it essentially must do a "deferred pop of BOS labe= l". In other words, if the datapath encounters an entropy-enabled AL or an= ELI, it must make a note of it and continue processing labels until it hit= s the BOS label, which it must pop. While certainly possible, this is a lo= t more convoluted and difficult to implement than what is specified in the = draft. Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_5E893DB832F57341992548CDBB333163A55C914900EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pablo,

 

=

These are some of the same conclusions to which= the EL authors came.  The deployment environment for FAT labels, pt-2= -pt, is more constrained than the deployment environment for ELs, any- 2-an= y, so presumably some of these cases could be handled in signaling, such th= at both endpoints know what to expect before packets start to flow.  H= owever, it might be nice to use a reserved ELI for FAT labels in order to h= ave a consistent data plane for both.

 

Thanks,=

 <= /p>

John

 

From: Pablo Frank [mailto:pabloisnot@gmail.com]
Sent: Friday= , February 17, 2012 8:40 AM
To: Alexander Vainshtein
Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] = Question about Entropy labels + GAL

 

Hi Sasha,

 

Even the relatively simple set of rules that you've defined below= glosses over a some added complexity in trying to do a hardware implementa= tion.  I think we can at least agree that this is not nearly as simple= as using reserved ELI (which a dumb parser can dispose of without needing = to even look anything up).  I guess I'm just nervous about the lookup = context of a label affecting the disposition of a label that is not necessa= rily next in the stack.  To me this feels like a slippery slope.  = ;What if, in the future, we come up with more "stuff" that goes b= etween the AL and the EL?  The permutations quickly multiply and this = will ultimately impact the cost of hardware.

 

Just s= omething to keep in mind as we go forward.

 

In any c= ase, I think there's enough uncertainty that the authors of type-4 VCCV sho= uld probably explicitly address how they expect it to interact with flow la= bels.

 

Pablo

On Thu, Feb 16, 2012 at 1:19 PM, Alexander = Vainshtein <Alexande= r.Vainshtein@ecitele.com> wrote:

Pablo,

Lots of= thanks for a prompt response.

 

I think that the sit= uation with GAL between the PW (application label) and flow label is much s= impler than what you have described. This logic is based on the fact "= application labels" can be easily recognized as such by the LSR that e= xamines them during label stack parsing.

 

When an a= pplication label is encountered, there are just three cases:

=
  1. It is BoS= - nothing new, pass to the corresponding application (PW forwarder, V= RF etc.) for handling. The data for this application directly follows the l= abel stack (may include CW in the case of PW or VPLS)
    2. =
  2. Not BoS and the next label is GAL - st= op parsing and pass to the "VCCV-4" handler, The data for the &qu= ot;VCCV-4 handler" application directly follows the label stack and st= arts with the ACH header.
  3. N= ot BoS and the next label is not GAL - treat the next label as the &qu= ot;flow label", i.e. pass to the corresponding application (may i= nclude CW in the case of PW or VPLS).

In the case of= MS-PWs, only T-PEs would treat the PW labels as "application labels&q= uot;, S-PEs would treat them as non-application labels. This is fully consi= stent with RFC 6073 which explains that if you want an S-PE to handle a VCC= V packet, you must use VCCV Type 3 (TTL expiration) possibly combined with = VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.

=

 

In other words, there is no need for ELI with th= e flow label.

 

Did I miss something= ?

 

My 2c,

Sasha

 

=

From: Pablo Frank [pabloisnot@gmail.com]
Sent: Thurs= day, February 16, 2012 6:22 PM
To: Alexander Vainshtein
Cc:= John E Drake; mpls@= ietf.org; pwe3@ietf.= org


Subject: Re: [mpl= s] Question about Entropy labels + GAL

 

Thanks Sasha.  I completely concur with your points 1 and 2.

 

As for point #3, that seems like the logical conclusion. &n= bsp;However, I think there's still a bit of awkwardness around implementing= this.  Both the original entropy-label draft and RFC 6391 have assume= d a simple pop-pop logic when you encounter an entropy-enabled AL or a flow= -enabled PW.  The moment GAL, or any other reserved label gets thrown = into the mix, the label disposition logic gets suddenly more complex.  = ;Instead of pop-pop, the hardware will have to do more complicated logic li= ke "IF this is a flow-enabled label AND the next label is ! GAL THEN p= op-pop ELSE IF ..., etc.".  While I have very programmable hardwa= re at my disposal, I prefer elegant and simple and this feels wrong.

 

It sounds like the authors of the entropy label draft hav= e recognized this problem and are now moving towards mandating the use of a= reserved ELI which unambiguously implies that the next label is entropy (s= o the hardware can go back to having simple pop-pop logic when it sees a re= served ELI).

 

Which brings me back to VCCV.  If= I'm doing type-1,2,3 VCCV, the situation is unambiguous.  If I encoun= ter any of these types of PWEs with flow-enabled, I can do a pop-pop.  = ;If for type-4 VCCV, we assume that the GAL is between the PW label and flo= w label (which I think was the intent), we're back to having ugly logic to = try and dispose of the GAL and flow label correctly.  A reserved ELI c= ould help disambiguate the situation in this case but this makes running ty= pe-4 VCCV with flow labels unattractive compared to type-1 VCCV.=

 

regards,

Pablo<= o:p>

 

On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtei= n <Alexander.Vainshtein@ecitele.com> wrote:

Pablo, John and all,

A couple of comments:

 

  1. Following a long discussion on the PWE3 WG mailing lis= t RFC 6423 has relaxed the original requirement for GAL being at the b= ottom of stack that have been defined in RFC 5586.
  2. My reading of RFC 6391 is that it mandates the= flow label to be at the bottom of the label stack for PW packets carr= ying user data. And it does not provide for ELI usage anywhere, be it a res= erved label or a signaled one.
  3. To the best of my understanding, the situation when GAL is used for fa= t PWs is not explicitly defined. Inserting GAL between the PW label an= d flow label (with the ACH header immediately following the label stack) se= ems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this form= at should be explicitly defined as the correct one?

= Regards,

     Sasha

&= nbsp;

 

 

 

 

 

 

 

From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of P= ablo Frank [pablo= isnot@gmail.com]
Sent: Thursday, February 16, 2012 12:24 AMTo: John E Drake
Cc: mpls@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] Question about = Entropy labels + GAL

Ah, good.  That certainly makes things more deterministic. &n= bsp;

 

I guess the question now becomes how will this affe= ct type-4 VCCV on fat pseudowires (RFC 6391)?  Will type-4 VCCV h= ave to mandate the use of ELIs when flow labels are present?  That see= ms too bad since the main advantage of type-4 VCCV seems to be to save a fe= w bytes on the wire.  This puts the overhead right back in so it may b= e more attractive to run fat PWEs with type-1 VCCV...

<= div>

 

Pablo

On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.net> wrote:<= /o:p>

Pablo,

 <= o:p>

Based upon Kireeti’s update in Taipe= i, we seem to going towards using a reserved label for ELI and making it al= ways required.

 

Thanks,

 

J= ohn  

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pabl= o Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: = mpls@ietf.org
= Subject: [mpls] Question about Entropy labels + GAL

 

I'm working on i= mplementation for entropy labels and I have a question about draft-iet= f-mpls-entropy-label-01.  Consider a scenario where I have received th= e following:

 

... | LSP label x | Entropy label | IPv4 payload | ...

 

Assume that I've si= gnaled that the LSP label wants entropy and an ELI is unnecessary.  Fo= llowing the procedures detailed in 4.3, the datapath would lookup labe= l x and see that it is expecting a possible entropy label and since x is no= t BOS, it pops the next label and then begins processing the IPv4 payload. =  So far, so good.  

 

However, I believe the following is legal as well= :

 

.= .. | LSP label x | GAL label | Entropy label | BFD payload | ...=

 

Alternatively,= an equally vexing scenario is:

 =

... | LSP label x | IPv4 explicit NULL | E= ntropy label | IPv4 payload | ...

 

There are probably other reserved labels that= are applicable as well.

 <= /p>

In either case, the draft doesn't clearly state what's= supposed to happen.  If I follow the procedures in 4.3, the data= path would end up popping the GAL or the explicit NULL label (thinking they= are entropy labels) and would then attempt to lookup the entropy label (wh= ich would result in erroneous behaviour).   The only additional guidan= ce that the draft gives is in section 6 where it suggests that GAL could be= treated as an application label.  But that doesn't seem helpful since= the LSP label must also be an application label (to handle the non-= GAL case) and will always be encountered first during label disposition. &n= bsp;Also, presumably I don't want all GALs to expect entropy so there's an = implied scoping of GAL.

 

It seems to me that when a datapath encounte= rs an entropy-enabled application label or an ELI, that it essentially must= do a "deferred pop of BOS label".  In other words, if the&n= bsp;datapath encounters an entropy-enabled AL or an ELI, it must make a not= e of it and continue processing labels until it hits the BOS label, which i= t must pop.  While certainly possible, this is a lot more convoluted a= nd difficult to implement than what is specified in the draft.  Is thi= s really the desired behaviour?

 =

The same question applies to type-4 VCCV with f= low labels.

 

regards,

Pablo

=

 

=

 

= This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

 

This e-mail message is intended for the recipie= nt only and contains information which is CONFIDENTIAL and which may be pro= prietary to ECI Telecom. If you have received this transmission in error, p= lease inform us by e-mail, phone or fax, and then delete the original and a= ll copies thereof.

 

= --_000_5E893DB832F57341992548CDBB333163A55C914900EMBX01HQjnprn_-- From Alexander.Vainshtein@ecitele.com Fri Feb 17 22:24:32 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 7F6FF21F86BA for ; Fri, 17 Feb 2012 22:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.58 X-Spam-Level: X-Spam-Status: No, score=-4.58 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 EQEdD9auaiRi for ; Fri, 17 Feb 2012 22:24:30 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 8F0FF21F86B9 for ; Fri, 17 Feb 2012 22:24:28 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1329546193!63364284!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 31716 invoked from network); 18 Feb 2012 06:23:14 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-7.tower-27.messagelabs.com with SMTP; 18 Feb 2012 06:23:14 -0000 X-AuditID: 93eaf2e7-b7f7e6d000000e6e-d2-4f3f4fd82830 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 72.B7.03694.8DF4F3F4; Sat, 18 Feb 2012 09:14:32 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 18 Feb 2012 08:24:25 +0200 From: Alexander Vainshtein To: Pablo Frank Date: Sat, 18 Feb 2012 08:22:37 +0200 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: AcztkoEAOL8ckp+uTiiyc1IWsA6d5gAcCfB4 Message-ID: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> , 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_A3C5DF08D38B6049839A6F553B331C76011659266629ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTuzoy74+bEtGrettcylUSxtauWG7UaSWQPWCMxCMrG3dvu4O7s tjOJG1ESQWVkLZXmUllgL3tsipVF5Wo/ej+gonwVlg+yJ2pYBtlMYyZE99d3z/ed8517OYfE tYfUOpLjReTjWRej0hD7u7p7DS+tqVZjzxWd+XBLmrnxxJkIc8n72ypzUXc1sYBIvxpsUaeX l3/H0l9se67OwFcXgPksz3tEVkR6OxJsFibDx+WxNj+j5+wWxsTovS7WhtyIFy0M6/Ui3s6k aPT/nPmSjOP1iLd57BzvsDBLVloNZvPsuQYTkxI/2ZQ4T5Pp5AQ9MrhZzqV3I0FgHUgvRdZV 485wyWJvxw4s/2PgBlEAXjeBQhBJQjoJbu+vGsRj4JNXIVUh0JBauhbAD427I5RLMYAd7QFC VqloC6w626KScQwdDy8ESn9n4zQH2071YTIm6KnwdtEtdSEgyWg6GZ7cv1WRm+GxlkZcDsfQ CfBiyC+HKXoF/P7sOFCsvuLwQF2PWiYiJWJPxbXftkBqru/eOUyxioONbWWY0jQNy68/xhUc C9+9/Rmh6GNh847QYGseeDAUBorZaHi3tI1Q9GNh3emXxD4wJjisbHBYSnBYihI3ws+PynAF z4Anj78fxLNgZe9DMDx+DKgrQCzn8oo5bofRNBPZOBG50Eybx10FlFHqrAH9ZVPqAU0CJopy 9qdYtRFsnuB314OxJMbEUlULU63aUTkeu9/JCs5s30YXEuoBJHEmhlraLMkpO+vfhHyeP9Qi 6fMDuG6kzSMNLS9mJxqN/78wcVQFKxWhHdJo5iLkRb4/dcaTJAOpzWmS/WgfcqD89ZxL/Etj ZKTcRpTUxl5ZQwle1i1wDoW/Bwxk8ZfOJ0BL8B4e6eKoXFlEyyLnRn6ojrxQWwcGBrpAnPQB 0VSRrIqS1m2oUpdkgkkmlFZ+qyCt0BClKwBZ3+o+zckKByfabl1Z/gPTpLdNWp42bcS41LWB A4kvcovhpA1Lm0582NQQ3T0tyTw9v3Vzdnj79YSahEtHhNIH4QZTSdmWyszaO62Xl9FnOm/u TNmzbFzCt7zaJiZ0vzI04VFmsj/H0Dl+zfk3q+IzQlkFyVPVj3uqj16cU6N6Ku562M4QgpM1 Tcd9AvsLBclp2isEAAA= Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Question about Entropy labels + GAL 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, 18 Feb 2012 06:24:32 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011659266629ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Pablo hi, Lots of thanks for a prompt response. Regarding "added complexity in trying to do a hardware implementation": I th= ink whatever complexity is there has been added by GAL following the AL, not= by the flow label (with or without ELI). This has been my main point for ob= jecting to what has become RFC 6423. Prior to that, you could handle an AL= exactly as you would handle any other label according to RFC 3031 - look i= t up in the ILM and perform the corresponding action which would be "pop and= forward an unlabeled (because your AL has been always BoS) packet to a non-= MPLS forwarder defined by the AL". And yes, I know that some implementations= did it differently - but the naive processing I've defined before had worke= d OK for PWs, VPLS and IP VPN. And RFC 6391 did not really change that: you could still forward a (possibly labeled) packet to a suitable non-MPLS f= orwarder, and the only change you needed would be for this forwarder to ign= ore the remainder of the label stack whatever it happened to be if it receiv= ed a labeled packet. GAL following the AL has changed this simple logic. You really had to distin= guish between ALs and "regular" labels in your MPLS forwarder. This means th= at your ILM lookup must now return a "this is an AL" indication to the forwa= rding HW. I do not see how this can be avoided if you want to support RFC 64= 23 - please consider the difference between the T-PE and S-PE operation in M= S-PWs as an example. At the same time once you implement that, support of flow labels on top of s= upporting GAL becomes trivial because, since RFC 6391, reserved labels (incl= uding GAL) MUST NOT be used as flow labels. I.e., a dumb parser would know t= hat if it has found an AL that is not BoS, it should only check for the next= label for being a reserved one. Having an ELI at this point would only make= life more complicated, because you would then to distinguish specifically b= etween GAL, ELI and, possibly, other reserved labels... My 2c, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Friday, February 17, 2012 6:39 PM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Hi Sasha, Even the relatively simple set of rules that you've defined below glosses ov= er a some added complexity in trying to do a hardware implementation. I thi= nk we can at least agree that this is not nearly as simple as using reserved= ELI (which a dumb parser can dispose of without needing to even look anythi= ng up). I guess I'm just nervous about the lookup context of a label affect= ing the disposition of a label that is not necessarily next in the stack. T= o me this feels like a slippery slope. What if, in the future, we come up w= ith more "stuff" that goes between the AL and the EL? The permutations quic= kly multiply and this will ultimately impact the cost of hardware. Just something to keep in mind as we go forward. In any case, I think there's enough uncertainty that the authors of type-4 V= CCV should probably explicitly address how they expect it to interact with f= low labels. Pablo On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainshtein > wrote: Pablo, Lots of thanks for a prompt response. I think that the situation with GAL between the PW (application label) and f= low label is much simpler than what you have described. This logic is based= on the fact "application labels" can be easily recognized as such by the LS= R that examines them during label stack parsing. When an application label is encountered, there are just three cases: 1. It is BoS - nothing new, pass to the corresponding application (PW forw= arder, VRF etc.) for handling. The data for this application directly follow= s the label stack (may include CW in the case of PW or VPLS) 2. Not BoS and the next label is GAL - stop parsing and pass to the "VCCV-= 4" handler, The data for the "VCCV-4 handler" application directly follows t= he label stack and starts with the ACH header. 3. Not BoS and the next label is not GAL - treat the next label as the "fl= ow label", i.e. pass to the corresponding application (may include CW in the= case of PW or VPLS). In the case of MS-PWs, only T-PEs would treat the PW labels as "application= labels", S-PEs would treat them as non-application labels. This is fully co= nsistent with RFC 6073 which explains that if you want an S-PE to handle a V= CCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined with= VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4. In other words, there is no need for ELI with the flow label. Did I miss something? My 2c, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Thursday, February 16, 2012 6:22 PM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Thanks Sasha. I completely concur with your points 1 and 2. As for point #3, that seems like the logical conclusion. However, I think t= here's still a bit of awkwardness around implementing this. Both the origin= al entropy-label draft and RFC 6391 have assumed a simple pop-pop logic when= you encounter an entropy-enabled AL or a flow-enabled PW. The moment GAL,= or any other reserved label gets thrown into the mix, the label disposition= logic gets suddenly more complex. Instead of pop-pop, the hardware will ha= ve to do more complicated logic like "IF this is a flow-enabled label AND th= e next label is ! GAL THEN pop-pop ELSE IF ..., etc.". While I have very pr= ogrammable hardware at my disposal, I prefer elegant and simple and this fee= ls wrong. It sounds like the authors of the entropy label draft have recognized this p= roblem and are now moving towards mandating the use of a reserved ELI which= unambiguously implies that the next label is entropy (so the hardware can g= o back to having simple pop-pop logic when it sees a reserved ELI). Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the situation i= s unambiguous. If I encounter any of these types of PWEs with flow-enabled,= I can do a pop-pop. If for type-4 VCCV, we assume that the GAL is between= the PW label and flow label (which I think was the intent), we're back to h= aving ugly logic to try and dispose of the GAL and flow label correctly. A= reserved ELI could help disambiguate the situation in this case but this ma= kes running type-4 VCCV with flow labels unattractive compared to type-1 VCC= V. regards, Pablo On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein > wrote: Pablo, John and all, A couple of comments: 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 has re= laxed the original requirement for GAL being at the bottom of stack that hav= e been defined in RFC 5586. 2. My reading of RFC 6391 is that it mandates the flow label to be at the= bottom of the label stack for PW packets carrying user data. And it does no= t provide for ELI usage anywhere, be it a reserved label or a signaled one. 3. To the best of my understanding, the situation when GAL is used for fat= PWs is not explicitly defined. Inserting GAL between the PW label and flow= label (with the ACH header immediately following the label stack) seems to= be fully compatible with both RFC 6423 and RFC 6391. Maybe this format shou= ld be explicitly defined as the correct one? Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf= .org] On Behalf Of Pablo Frank [pabloisnot@gma= il.com] Sent: Thursday, February 16, 2012 12:24 AM To: John E Drake Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat pse= udowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs when= flow labels are present? That seems too bad since the main advantage of ty= pe-4 VCCV seems to be to save a few bytes on the wire. This puts the overhe= ad right back in so it may be more attractive to run fat PWEs with type-1 VC= CV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake > wrote: Pablo, Based upon Kireeti=92s update in Taipei, we seem to going towards using a re= served label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-bounc= es@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question about= draft-ietf-mpls-entropy-label-01. Consider a scenario where I have receive= d the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is unn= ecessary. Following the procedures detailed in 4.3, the datapath would look= up label x and see that it is expecting a possible entropy label and since x= is not BOS, it pops the next label and then begins processing the IPv4 payl= oad. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the GA= L or the explicit NULL label (thinking they are entropy labels) and would th= en attempt to lookup the entropy label (which would result in erroneous beha= viour). The only additional guidance that the draft gives is in section 6= where it suggests that GAL could be treated as an application label. But t= hat doesn't seem helpful since the LSP label must also be an application lab= el (to handle the non-GAL case) and will always be encountered first during= label disposition. Also, presumably I don't want all GALs to expect entrop= y so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicatio= n label or an ELI, that it essentially must do a "deferred pop of BOS label"= . In other words, if the datapath encounters an entropy-enabled AL or an EL= I, it must make a note of it and continue processing labels until it hits th= e BOS label, which it must pop. While certainly possible, this is a lot mor= e convoluted and difficult to implement than what is specified in the draft.= Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76011659266629ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
Pablo hi,
Lots of thanks for a prompt response.
 
Regarding "added complexity in= trying to do a hardware implementation": I think whatever complex= ity is there has been added by GAL following the AL, not by the flow label (= with or without ELI). This has been my main point for objecting to what has become RFC 6423.  Prior to that, you c= ould handle an  AL exactly as you would handle  any other lab= el according to RFC 3031 - look it up in the ILM and perform the corres= ponding action which would be "pop and forward an unlabeled (because your AL has been always BoS) packet to a non-MPLS fo= rwarder defined by the AL". And yes, I know that some implementations d= id it differently - but the naive processing I've defined before had worked= OK for PWs, VPLS and IP VPN.  And RFC 6391 did not really change that:
you could still forward a (possibly labe= led) packet to a suitable non-MPLS forwarder, and  the only change you= needed would be for this forwarder to ignore the remainder of the label sta= ck whatever it happened to be if it received a labeled packet.
 
GAL following the AL has changed this si= mple logic. You really had to distinguish between ALs and "regular"= ; labels in your MPLS forwarder. This means that your ILM lookup must now re= turn a "this is an AL" indication to the forwarding HW. I do not see how this can be avoided if you want to support= RFC 6423 - please consider the difference between the T-PE and= S-PE operation in MS-PWs as an example.
 
At the same time once y= ou implement that, support of flow labels on top of supporting GAL beco= mes trivial because, since RFC 6391, reserved labels (including GAL) MU= ST NOT be used as flow labels. I.e., a dumb parser would know that if it has found an AL that is not BoS, it sho= uld only check for the next label for being a reserved one. Having an ELI at= this point would only make life more complicated, because you would then to= distinguish specifically between GAL, ELI and, possibly, other reserved labels...
 
My 2c,
     Sasha
 
From: Pablo Frank= [pabloisnot@gmail.com]
Sent: Friday, February 17, 2012 6:39 PM
To: Alexander Vainshtein
Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] Question about Entropy labels + GAL

Hi Sasha,

Even the relatively simple set of rules that you've defined below gloss= es over a some added complexity in trying to do a hardware implementation. &= nbsp;I think we can at least agree that this is not nearly as simple as usin= g reserved ELI (which a dumb parser can dispose of without needing to even look anything up).  I guess I'm= just nervous about the lookup context of a label affecting the disposition= of a label that is not necessarily next in the stack.  To me this feel= s like a slippery slope.  What if, in the future, we come up with more "stuff" that goes between the AL and= the EL?  The permutations quickly multiply and this will ultimately im= pact the cost of hardware.

Just something to keep in mind as we go forward.

In any case, I think there's enough uncertainty that the authors of typ= e-4 VCCV should probably explicitly address how they expect it to interact w= ith flow labels.

Pablo

On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainsh= tein <Alexander.Vainshtein= @ecitele.com> wrote:
Pablo,
Lots of thanks for a prompt response.
 
I think that the situation with GAL betw= een the PW (application label) and flow label is much simpler than what you= have described. This logic is based on the fact "application labels&qu= ot; can be easily recognized as such by the LSR that examines them during label stack parsing.
 
When an application label is encountered= , there are just three cases:
  1. It is BoS - nothing ne= w, pass to the corresponding application (PW forwarder, V= RF etc.) for handling. The data for this application directly follows= the label stack (may include CW in the case of PW or VPLS)
  2. Not BoS<= a> and the next label is GAL - stop parsing and pass to the "= ;VCCV-4" handler, The data for the "VCCV-4 handler" applicati= on directly follows the label stack and starts with the ACH header.
  3. Not BoS and the n= ext label is not GAL - treat the next label as the "flow label", i= .e. pass to the corresponding application (may include CW in the= case of PW or VPLS).

In the case of MS-PWs, only T-PEs would tr= eat the PW labels as "application labels", S-PEs would treat them= as non-application labels. This is fully consistent with RFC 6073 which exp= lains that if you want an S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined wi= th VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.

 

In other words, there is no need for ELI w= ith the flow label.

 

Did I miss something?

 

My 2c,

Sasha

 

Fro= m: Pablo Frank [pabloisnot@gmail= .com]
Sent: Thursday, February 16, 2012 6:22 PM
To: Alexander Vainshtein
Cc: John E Drake; mpls@ietf.org<= a>; pwe3@ietf.org

Subject: Re: [mpls] Question about Entropy labels += GAL

Thanks Sasha.  I completely concur with your points 1 and 2.

As for point #3, that seems like the logical conclusion.  However,= I think there's still a bit of awkwardness around implementing this.  = Both the original entropy-label draft and RFC 6391 have assumed a simple pop= -pop logic when you encounter an entropy-enabled AL or a flow-enabled PW.  The moment GAL, or any other reserved label= gets thrown into the mix, the label disposition logic gets suddenly more co= mplex.  Instead of pop-pop, the hardware will have to do more complicat= ed logic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". &nb= sp;While I have very programmable hardware at my disposal, I prefer elegant= and simple and this feels wrong.

It sounds like the authors of the entropy label draft have recognized t= his problem and are now moving towards mandating the use of a reserved ELI w= hich unambiguously implies that the next label is entropy (so the hardware c= an go back to having simple pop-pop logic when it sees a reserved ELI).

Which brings me back to VCCV.  If I'm doing type-1,2,3 VCCV, the s= ituation is unambiguous.  If I encounter any of these types of PWEs wit= h flow-enabled, I can do a pop-pop.  If for type-4 VCCV, we assume that= the GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try and= dispose of the GAL and flow label correctly.  A reserved ELI could hel= p disambiguate the situation in this case but this makes running type-4 VCCV= with flow labels unattractive compared to type-1 VCCV.

regards,
Pablo

On Thu, Feb 16, 2012 at 1:22 AM, Alexander V= ainshtein <Al= exander.Vainshtein@ecitele.com> wrote:
Pablo, John and all,
A couple of comments:
 
  1. Following a long discussion on the PWE3 WG mailing list RFC 6423 ha= s relaxed the original requirement for GAL being at the bottom o= f stack that have been defined in RFC 5586.
  2. My reading of RFC 6391 is that it mandates the flow label to b= e at the bottom of the label stack for PW packets carrying user= data. And it does not provide for ELI usage anywhere, be it a reserved labe= l or a signaled one.
  3. To the best of my understanding, the situation when GAL is used for= fat PWs is not explicitly defined. Inserting GAL between the PW label= and flow label (with the ACH header immediately following the label stack)= seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the co= rrect one?

Regards,

     Sasha

 

 
 
 
 
 
 
 
From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo F= rank [pabloisnot@gmail.com]
Sent: Thursday, February 16, 2012 12:24 AM
To: John E Drake
Cc: mpls@ietf.org;= pwe3@ietf.org
Subject: Re: [mpls] Question about Entropy labels += GAL

Ah, good.  That certainly makes things more deterministic.  

I guess the question now becomes how will this affect type-4 VCCV on fa= t pseudowires (RFC 6391)?  Will type-4 VCCV have to= mandate the use of ELIs when flow labels are present?  That seems too= bad since the main advantage of type-4 VCCV seems to be to save a few bytes on the wire.  This puts the overhead right b= ack in so it may be more attractive to run fat PWEs with type-1 VCCV...

Pablo

On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.net> wrote:

Pablo,

 

Based upon Kireeti=92s up= date in Taipei, we seem to going towards using a reserved label for ELI and= making it always required.

 

Thanks,

 

John  

 

From: mpl= s-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Wednesday, February 15, 2012 7:30 AM
To: mpls@ietf.org<= br> Subject: [mpls] Question about Entropy labels + GAL=

 

I'm working on implementation for entropy labels and= I have a question about draft-ietf-mpls-entropy-label-01.  Consid= er a scenario where I have received the following:

 

... | LSP label x | Entropy label | IPv4 payload | ..= .

 

Assume that I've signaled that the LSP label wants en= tropy and an ELI is unnecessary.  Following the procedures detailed in= 4.3, the datapath would lookup label x and see that it i= s expecting a possible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 pa= yload.  So far, so good.  

 

However, I believe the following is legal as well:=

 

... | LSP label x | GAL label | Entropy label | BFD p= ayload | ...

 

Alternatively, an equally vexing scenario is:<= u>

 

... | LSP label x | IPv4 explicit NULL | Entropy labe= l | IPv4 payload | ...

 

There are probably other reserved labels that are app= licable as well.

 

In either case, the draft doesn't clearly state what'= s supposed to happen.  If I follow the procedures in 4.3, the data= path would end up popping the GAL or the explicit NULL label (= thinking they are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous b= ehaviour).   The only additional guidance that the draft= gives is in section 6 where it suggests that GAL could be treated as an app= lication label.  But that doesn't seem helpful since the LSP label must also be an application label (to ha= ndle the non-GAL case) and will always be encountered first during label dis= position.  Also, presumably I don't want all GALs to expect entropy so= there's an implied scoping of GAL.

 

It seems to me that when a datapath encounters an entropy-enabled application label or an ELI, that it essenti= ally must do a "deferred pop of BOS label".  In other words,= if the datapath encounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels unti= l it hits the BOS label, which it must pop.  While certainly possible,= this is a lot more convoluted and difficult to implement than what is speci= fied in the draft.  Is this really the desired behaviour?

 

The same question applies to type-4 VCCV with flow la= bels.

 

regards,

Pablo

 


This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76011659266629ILPTMAIL02e_-- From Manuel.Paul@telekom.de Mon Feb 20 00:23: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 35AD321F86DE for ; Mon, 20 Feb 2012 00:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 x6LLNhgLnlDp for ; Mon, 20 Feb 2012 00:23:41 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB5821F86DD for ; Mon, 20 Feb 2012 00:23:40 -0800 (PST) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 20 Feb 2012 09:23:38 +0100 Received: from HE101452.emea1.cds.t-internal.com ([169.254.2.26]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Mon, 20 Feb 2012 09:23:38 +0100 From: To: , , , , , , Date: Mon, 20 Feb 2012 09:23:37 +0100 Thread-Topic: [mpls] Addition on this poll - the IPR aspect (Was Re: Poll on draft-koike-mpls-tp-temporal-hitless-psm) Thread-Index: Acztk8A+rdxiQQzBQei0ff6InEg1dwAhy3fA Message-ID: <9435EDACD941174099E143BCA2BCD615F91C0414B1@HE101452.emea1.cds.t-internal.com> References: <4F327811.1000700@pi.nu> <4F3E8461.9070002@pi.nu> In-Reply-To: <4F3E8461.9070002@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Mon, 20 Feb 2012 08:23:45 -0000 SGksDQoNCkknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQta29p a2UtbXBscy10cC10ZW1wb3JhbC1oaXRsZXNzLXBzbS4NCg0KQmVzdCBSZWdhcmRzDQpNYW51ZWwg KGNvLWF1dGhvcikNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZg0KPiBMb2EgQW5kZXJzc29uDQo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTcsIDIwMTIg NTo0NiBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQt a29pa2UtbXBscy10cC10ZW1wb3JhbC0NCj4gaGl0bGVzcy1wc21AdG9vbHMuaWV0Zi5vcmc7IFJv c3MgQ2FsbG9uOyBHZW9yZ2UgU3dhbGxvdzsgQWRyaWFuIEZhcnJlbA0KPiBTdWJqZWN0OiBbbXBs c10gQWRkaXRpb24gb24gdGhpcyBwb2xsIC0gdGhlIElQUiBhc3BlY3QgKFdhcyBSZTogUG9sbCBv bg0KPiBkcmFmdC1rb2lrZS1tcGxzLXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtKQ0KPg0KPiBBbGws DQo+DQo+IHRoaXMgcG9sbCBoYXMgYmVlbiBydW5uaW5nIGZvciBzb21lIHRpbWUsIGFjY29yZGlu ZyB0aGUgcHJvY2VzcyB0aGUNCj4gd2cgY2hhaXIgb3V0bGluZWQgaW4gYSByZWNlbnQgbWFpbCBp dCBzaG91bGQgaGF2ZSBiZWVuIHByZWNlZGVkDQo+IGJ5IGEgbWFpbCByZW1pbmRpbmcgYWJvdXQg SVBScy4gV2UgZGlkbid0IGhhdmUgdGhhdCBwcm9jZXNzIHJlYWxseQ0KPiBpbiBwbGFjZSB3aGVu IHRoZSBwb2xsIHdhcyBzdGFydGVkLiBTbyBoZXJlIGNvbWVzIHRoZSBJUFIgcmVtZWluZGVyLg0K Pg0KPiBBcyB5b3UgY2FuIHNlZSBmcm9tIHRoZSBwb2xsIHRoZSB3ZyBjaGFpcnMgaGF2ZSBzZW50 IG91dCB0aGUgYXV0aG9ycw0KPiBoYXZlIGFza2VkIGZvciBkcmFmdC1rb2lrZS1tcGxzLXRwLXRl bXBvcmFsLWhpdGxlc3MtcHNtIHRvIGJlDQo+IGNvbnNpZGVyZWQgZm9yIGFkb3B0aW9uIGFzIGEg V0cgZG9jdW1lbnQuIFdlIHdvdWxkIGxpa2UgdG8gY2hlY2sNCj4gd2hldGhlciB0aGVyZSBpcyBJ UFIgb24gdGhlIGRvY3VtZW50IHRoYXQgbmVlZHMgdG8gYmUgZGlzY2xvc2VkLg0KPiBXZSB3aWxs IHdlaWdoIHRoaXMgaW4gd2hlbiB3ZSBqdWRnZSB0aGUgY29uc2Vuc3VzIG9uIHRoZSBjYWxsIGZv cg0KPiBhZG9wdGlvbi4NCj4NCj4gQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byBkcmFmdC1rb2lrZS1tcGxzLXRwLXRlbXBvcmFsLQ0KPiBoaXRsZXNzLXBzbT8gSWYgc28s IGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURg0KPiBJ UFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0 YWlscykuDQo+DQo+IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNv bnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvDQo+IHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudA0KPiBJUFIuIFRoaXMg ZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3Bv bnNlDQo+IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9y Lg0KPg0KPiBJZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3Qg bGlzdGVkIGFzIGFuIGF1dGhvciBvcg0KPiBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGlj aXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkNCj4gSVBSIHRoYXQgaGFz IG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0K Pg0KPiAvTG9hDQo+DQo+IChhcyBNUExTIFdHIGNvLWNoYWlyKQ0KPg0KPg0KPg0KPiBPbiAyMDEy LTAyLTA4IDE0OjI2LCBMb2EgQW5kZXJzc29uIHdyb3RlOg0KPiA+IFdvcmtpbmcgR3JvdXAsDQo+ ID4NCj4gPiB0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCB0byBzZWUgaWYgdGhlcmUg aXMgc3VwcG9ydCB0byBtYWtlDQo+ID4NCj4gPiBkcmFmdC1rb2lrZS1tcGxzLXRwLXRlbXBvcmFs LWhpdGxlc3MtcHNtLTA0DQo+ID4NCj4gPiBtcGxzIHdvcmtpbmcgZ3JvdXAgZHJhZnRzLg0KPiA+ DQo+ID4gUGxlYXNlZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd29ya2luZyBncm91 cCBtYWlsaW5nIGxpc3QNCj4gPiAobXBsc0BpZXRmLm9yZykuDQo+ID4NCj4gPiBUaGlzIHBvbGwg ZW5kcyBGZWJydWFyeSAyMiwgMjAxMiENCj4gPg0KPiA+IExvYQ0KPiA+IGZvciB0aGUgbXBscyB3 ZyBjaGFpcnMNCj4gPg0KPiA+DQo+DQo+IC0tDQo+DQo+DQo+IExvYSBBbmRlcnNzb24gICAgICAg ICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQo+IFNy IFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBF cmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUy IDEzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYg NzY3IDcyIDkyIDEzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From wwwrun@rfc-editor.org Mon Feb 20 14:58: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 3615321E8033; Mon, 20 Feb 2012 14:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, 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 uwmjo+TdZkV2; Mon, 20 Feb 2012 14:58:19 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 710E421E802D; Mon, 20 Feb 2012 14:58:19 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 05CC6B1E00C; Mon, 20 Feb 2012 14:53:15 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120220225315.05CC6B1E00C@rfc-editor.org> Date: Mon, 20 Feb 2012 14:53:15 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6511 on Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths 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, 20 Feb 2012 22:58:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6511 Title: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths Author: Z. Ali, G. Swallow, R. Aggarwal Status: Standards Track Stream: IETF Date: February 2012 Mailbox: zali@cisco.com, swallow@cisco.com, raggarwa_1@yahoo.com Pages: 10 Characters: 21767 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt URL: http://www.rfc-editor.org/rfc/rfc6511.txt There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Feb 20 14:58: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 16AB721E803A; Mon, 20 Feb 2012 14:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.878 X-Spam-Level: X-Spam-Status: No, score=-103.878 tagged_above=-999 required=5 tests=[AWL=1.199, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, 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 1CTSwAvSvuxO; Mon, 20 Feb 2012 14:58:39 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7B60421E801D; Mon, 20 Feb 2012 14:58:38 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 09C76B1E010; Mon, 20 Feb 2012 14:53:33 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120220225334.09C76B1E010@rfc-editor.org> Date: Mon, 20 Feb 2012 14:53:33 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6512 on Using Multipoint LDP When the Backbone Has No Route to the Root 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, 20 Feb 2012 22:58:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6512 Title: Using Multipoint LDP When the Backbone Has No Route to the Root Author: IJ. Wijnands, E. Rosen, M. Napierala, N. Leymann Status: Standards Track Stream: IETF Date: February 2012 Mailbox: ice@cisco.com, erosen@cisco.com, mnapierala@att.com, n.leymann@telekom.de Pages: 12 Characters: 24352 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-mldp-recurs-fec-04.txt URL: http://www.rfc-editor.org/rfc/rfc6512.txt The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core. This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From martin.vigoureux@alcatel-lucent.com Tue Feb 21 06:09: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 B7DF021F8507 for ; Tue, 21 Feb 2012 06:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.249 X-Spam-Level: X-Spam-Status: No, score=-108.249 tagged_above=-999 required=5 tests=[AWL=2.000, 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 Isigmewtknbu for ; Tue, 21 Feb 2012 06:09:10 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id CE35421F8503 for ; Tue, 21 Feb 2012 06:09:09 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1LDX8Bf009003 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 21 Feb 2012 15:09:06 +0100 Received: from [172.27.205.108] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Feb 2012 15:08:46 +0100 Message-ID: <4F43A56E.1080606@alcatel-lucent.com> Date: Tue, 21 Feb 2012 15:08:46 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 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] 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: Tue, 21 Feb 2012 14:09:10 -0000 All, 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). Requests with missing information will not be considered. Please send the requests before March 12th. Please be aware that we might not be able to satisfy all requests. Thank you. regards, martin From koike.yoshinori@lab.ntt.co.jp Tue Feb 21 20:21: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 9A20321F88A0 for ; Tue, 21 Feb 2012 20:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 j9PMQ2jZ4+th for ; Tue, 21 Feb 2012 20:21:50 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id DC03D21F889F for ; Tue, 21 Feb 2012 20:21:49 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id q1M4Li32004036; Wed, 22 Feb 2012 13:21:44 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 65AE365EC; Wed, 22 Feb 2012 13:21:44 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 5CCF565EB; Wed, 22 Feb 2012 13:21:44 +0900 (JST) Received: from [129.60.11.43] (koike-pc.nslab.ecl.ntt.co.jp [129.60.11.43]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q1M4LiVt021030; Wed, 22 Feb 2012 13:21:44 +0900 Message-ID: <4F446E08.8090302@lab.ntt.co.jp> Date: Wed, 22 Feb 2012 13:24:40 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Zhenlong Cui References: <4F327811.1000700@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int Subject: [mpls] Simultaneity of multi-level HPSM (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: Wed, 22 Feb 2012 04:21:50 -0000 Hi Zhenlong, Thank you for your comment. I'm sorry for this late reply. As we wrote in the same section, a combination of multi-level and "simultaneous monitoring" is the most powerful tool for accurately diagnosing the performance of a transport path. However I think it's better to add some texts for clarification in the section. We will refine the section using your proposed text next time we update the draft. Editors already discussed the necessity of simultaneity of multi-level HPSMs before. The following is just a reference information. Our fist priority is to request a tool to diagnose a degraded point without affecting transport path. From that perspective, a single-level HPSM is mandatory. Secondly, multi-level HPSMs can make the detection of a degraded point more efficient. Therefore, it is an option in the current draft. In addition, the simultaneity of multi-level HPSMs is related to an accuracy of the measurements which can make the detection much more efficient. Therefore, it is also an option. (I understand that it is not clear in the texts.) Best regards, Yoshinori (2012/02/13 9:52), Zhenlong Cui wrote: > Yes/support. > > I would like to raise some comments regarding section 6. > > I think performance monitoring is different from the survivability analysis, as it has a certain time-dependent behavior. Therefore, > I think the on-demand single-level segment monitoring must "timely coordinate" with the other levels that include the pro-active > end-to-end monitoring. > > I suggest adding some description to section 6 along these lines: > > In order to increase the accuracy of performance monitoring, > on-demand multi-level performance monitoring must have the ability to > execute at all levels at the same time. > > Best Regards, > zhenlong > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Wednesday, February 08, 2012 10:27 PM >> 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 >> Subject: [mpls] Poll on draft-koike-mpls-tp-temporal-hitless-psm >> >> 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 >> _______________________________________________ >> 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 > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From koike.yoshinori@lab.ntt.co.jp Tue Feb 21 20:22: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 6236021F88A0 for ; Tue, 21 Feb 2012 20:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 4hR7kbRCxivQ for ; Tue, 21 Feb 2012 20:22:50 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id C0D1321F889F for ; Tue, 21 Feb 2012 20:22:49 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id q1M4MnuD004273; Wed, 22 Feb 2012 13:22:49 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 16A5AE008D; Wed, 22 Feb 2012 13:22:49 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 0B32FE008A; Wed, 22 Feb 2012 13:22:49 +0900 (JST) Received: from [129.60.11.43] (koike-pc.nslab.ecl.ntt.co.jp [129.60.11.43]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q1M4MmBT023886; Wed, 22 Feb 2012 13:22:48 +0900 Message-ID: <4F446E48.8000303@lab.ntt.co.jp> Date: Wed, 22 Feb 2012 13:25:44 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mpls@ietf.org, ahmpls-tp@lists.itu.int 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: Wed, 22 Feb 2012 04:22:50 -0000 Hi, I'm not aware of any IPR that applies to draft-koike-mpls-tp-temporal- hitless-psm. Best regards, Yoshinori(co-author) (2012/02/18 1: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 >> >> > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From satoshi.ueno@ntt.com Tue Feb 21 23:22: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 69B8B21F87EF for ; Tue, 21 Feb 2012 23:22:29 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 TTomoTPfMbt3 for ; Tue, 21 Feb 2012 23:22:28 -0800 (PST) Received: from mgw3.noc.ntt.com (mgw3.noc.ntt.com [210.160.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5537F21F87C1 for ; Tue, 21 Feb 2012 23:22:28 -0800 (PST) Received: from mop3.noc.ntt.com by mgw3.noc.ntt.com (NTT-Com MailSV) with ESMTP id q1M7MQ9R018765 for ; Wed, 22 Feb 2012 16:22:26 +0900 (JST) Received: from mip01.noc.ntt.com (mvi1.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0LZS008XR9TERJ@ntt.com> for mpls@ietf.org; Wed, 22 Feb 2012 16:22:26 +0900 (JST) Date: Wed, 22 Feb 2012 16:22:25 +0900 From: "Satoshi UENO" In-reply-to: <4F3E8461.9070002@pi.nu> To: mpls@ietf.org Message-id: <000501ccf132$ba052560$2e0f7020$@ntt.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: ja Content-transfer-encoding: 7bit Thread-index: AQGEX7c4LqRbh0Xto+/T/rid8RYTFAD8xdSFltG/hFA= x-ccmail-original-to: mpls@ietf.org References: <4F327811.1000700@pi.nu> <4F3E8461.9070002@pi.nu> 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: Wed, 22 Feb 2012 07:22:29 -0000 All, I'm not aware of any IPR that applies to draft-koike-mpls-tp-temporal-hitless-psm. Best regards, Satoshi(co-author) > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Saturday, February 18, 2012 1:46 AM > 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 > Subject: Addition on this poll - the IPR aspect (Was Re: [mpls] Poll on > draft-koike-mpls-tp-temporal-hitless-psm) > > 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 adrian@olddog.co.uk Wed Feb 22 07:17: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 60B3121F87B3 for ; Wed, 22 Feb 2012 07:17:14 -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=[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 jRbG0wTX+jhb for ; Wed, 22 Feb 2012 07:17:10 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 08EB421F87A3 for ; Wed, 22 Feb 2012 07:17:09 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q1MFH8Gp028691 for ; Wed, 22 Feb 2012 15:17:09 GMT Received: from 950129200 (42-177.79-83.cust.bluewin.ch [83.79.177.42]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q1MFGj94028327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 22 Feb 2012 15:16:49 GMT From: "Adrian Farrel" To: References: <20120222151252.32262.82157.idtracker@ietfa.amsl.com> In-Reply-To: <20120222151252.32262.82157.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2012 15:16:45 -0000 Message-ID: <03a301ccf174$ff953290$febf97b0$@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: AQGdS0dQFbRu6GyAeWPtVTnp+xX6JJaoUwDw Content-Language: en-gb Subject: [mpls] FW: Last Call: (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC 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: Wed, 22 Feb 2012 15:17:14 -0000 Hi MPLS WG, You will want to be aware of this IETF Last Call. Please send any comments as per the instructions for IETF Last Call (i.e., see below) and not to the MPLS mailing list. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 22 February 2012 15:13 > To: IETF-Announce > Subject: Last Call: (Allocation of an > Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to > Informational RFC > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Allocation of an Associated Channel Code Point for Use by ITU-T > Ethernet based OAM' > 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-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 > > This document assigns an Associated Channel Type code point for > carrying Ethernet based Operations, Administration, and Management > messages in the MPLS Generic Associated Channel (G-ACh). > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ > > > 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 martin.vigoureux@alcatel-lucent.com Mon Feb 27 03:06: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 0C64921F86A4 for ; Mon, 27 Feb 2012 03:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.986 X-Spam-Level: X-Spam-Status: No, score=-107.986 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_20=-0.74, 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 ZN-EwUW74jTU for ; Mon, 27 Feb 2012 03:06:41 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 23A2521F86A2 for ; Mon, 27 Feb 2012 03:06:40 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1RB6VkG016675 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 27 Feb 2012 12:06:39 +0100 Received: from [172.27.205.108] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Feb 2012 12:06:36 +0100 Message-ID: <4F4B63BC.2010402@alcatel-lucent.com> Date: Mon, 27 Feb 2012 12:06:36 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 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] MPLS Sessions @IETF 83 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, 27 Feb 2012 11:06:42 -0000 All, just to let you know that the MPLS WG sessions are currently scheduled as indicated below: mpls session 1 (2.5 hours) Tuesday, Morning Session I 0900-1130 Room Name: 242AB mpls session 2 (2 hours) Friday, Morning Session I 0900-1100 Room Name: Maillot Note that the IETF agenda is subject to change martin From tnadeau@lucidvision.com Mon Feb 27 13:10: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 D3E1F21E803A for ; Mon, 27 Feb 2012 13:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, 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 aEfc4Z9ZSYgH for ; Mon, 27 Feb 2012 13:10:36 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 09ACF21E801A for ; Mon, 27 Feb 2012 13:10:35 -0800 (PST) Received: from [192.168.1.53] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 8486B1536C8 for ; Mon, 27 Feb 2012 16:10:35 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/alternative; boundary="Apple-Mail=_7540C86B-EB86-44DA-BC42-A00C59C40694" Date: Mon, 27 Feb 2012 16:10:35 -0500 Message-Id: <80CAFB37-DF32-45AA-9D95-0C74E4BA935F@lucidvision.com> To: mpls@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [mpls] The MPLS 2012 International Conference Call For Papers 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, 27 Feb 2012 21:10:37 -0000 --Apple-Mail=_7540C86B-EB86-44DA-BC42-A00C59C40694 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The MPLS 2012 International Conference, the 15th Annual International Conference on MPLS and Related Technologies, will be held October 28 - 31, 2012, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 30, 2012. If you want further information on MPLS 2012 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2012/call_for_papers/cfp.htm Many of these topics have been of interest to members of in the past, and many people active on this list have been presenters at past events. On behalf of the Technical Planning Committee --Apple-Mail=_7540C86B-EB86-44DA-BC42-A00C59C40694 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The MPLS 2012 International = Conference, the 15th Annual International
31, 2012, in Washington, DC. The Technical Program = Committee is
soliciting abstracts summarizing a = proposed presentation representing
original/unpublished = work covering cutting-edge topics.

Presentations covering new technologies and = operational experience are
solicited from network = equipment vendors, service/transport providers,
government = agencies, the research community, and enterprise users.
The deadline for submission of presentation = proposals is April 30, 2012.
If you want further = information on MPLS 2012 or want to submit a
presentation = abstract, please see the following URL:

Many of these topics have = been of interest to members of <this community>

On behalf of the Technical Planning = Committee
= --Apple-Mail=_7540C86B-EB86-44DA-BC42-A00C59C40694-- From curtis@occnc.com Mon Feb 27 18:22: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 B1BB821F8574 for ; Mon, 27 Feb 2012 18:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 mWMwZYp5kDVo for ; Mon, 27 Feb 2012 18:22:21 -0800 (PST) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88021F856F for ; Mon, 27 Feb 2012 18:22:21 -0800 (PST) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q1S2MGDu084801; Mon, 27 Feb 2012 18:22:17 -0800 (PST) (envelope-from curtis@occnc.com) Message-Id: <201202280222.q1S2MGDu084801@gateway.ipv6.occnc.com> To: mpls@ietf.org From: Curtis Villamizar Date: Mon, 27 Feb 2012 21:22:16 -0500 Subject: [mpls] MPLS-TP Multipath X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 02:22:25 -0000 FYI- Please discuss this on MPLS rather than on RTGWG. A separate message was sent to each WG to prevent accidental cross-posting. Sorry for the duplicate for those subscribed to both mailing lists. Curtis Briefly changes are as follows: mpls-tp-multipath: Change of author affiliation Switch from CCAMP to MPLS WG (error in prior draft) Numerous spelling corrections Added paragraph citing scaling work in RFC5439 and relevance. mpls-tp-multipath-te-extn: Change of author affiliation Numerous spelling corrections Multipath Link Capability TLV is added to Interface_ID, not Link Identification TLV as in prior version. ------- A new version of I-D, draft-villamizar-mpls-tp-multipath-02.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-tp-multipath Revision: 02 Title: Use of Multipath with MPLS-TP and MPLS Creation date: 2012-02-27 WG ID: Individual Submission Number of pages: 35 Abstract: Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over current high bandwidth multipath implementations. The tradeoffs involved in using multipath techniques with MPLS and MPLS-TP are described. Requirements are discussed which enable full MPLS-TP compliant LSP including full OAM capability to be carried over MPLS LSP which are traversing multipath links. Other means of supporting MPLS-TP coexisting with MPLS and multipath are discussed. ------- A new version of I-D, draft-villamizar-mpls-tp-multipath-te-extn-01.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-tp-multipath-te-extn Revision: 01 Title: Multipath Extensions for MPLS Traffic Engineering Creation date: 2012-02-27 WG ID: Individual Submission Number of pages: 26 Abstract: Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of carrying LSP with strict packet ordering requirements over multipath and and carrying LSP with strict packet ordering requirements within LSP without violating requirements to maintain packet ordering. LSP with strict packet ordering requirements include MPLS-TP LSP. OSPF-TE and ISIS-TE extensions defined here indicate node and link capability regarding support for ordered aggregates of traffic, multipath traffic distribution, and abilities to support multipath load distribution differently per LSP. RSVP-TE extensions either identifies an LSP as requiring strict packet order, or identifies an LSP as carrying one or more LSP that requires strict packet order at a given depth in the label stack, or identifies an LSP as having no restrictions on packet ordering except the restriction to avoid reordering microflows. In addition an extension indicates whether the first nibble of payload will reliably indicate whether payload is IPv4, IPv6, or other type of payload, most notably pseudowire using a pseudowire control word. ------- From balavenkata@aim.com Tue Feb 28 22:45: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 6234921E804E for ; Tue, 28 Feb 2012 22:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 AOSymbhhNTLz for ; Tue, 28 Feb 2012 22:45:58 -0800 (PST) Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97521E8043 for ; Tue, 28 Feb 2012 22:45:58 -0800 (PST) Received: from mtaomg-ma04.r1000.mx.aol.com (mtaomg-ma04.r1000.mx.aol.com [172.29.41.11]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id q1T6jrg6003458 for ; Wed, 29 Feb 2012 01:45:53 -0500 Received: from core-mra002b.r1000.mail.aol.com (core-mra002.r1000.mail.aol.com [172.29.194.69]) by mtaomg-ma04.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id D76F3E000088 for ; Wed, 29 Feb 2012 01:45:52 -0500 (EST) References: To: mpls@ietf.org In-Reply-To: X-MB-Message-Source: WebUI MIME-Version: 1.0 From: Bala Venkata X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CEC4C4EA33C8DB_9B4_1B98D_webmail-m055.sysops.aol.com" X-Mailer: AOL Webmail 35647-STANDARD Received: from 115.249.191.100 by webmail-m055.sysops.aol.com (64.12.158.155) with HTTP (WebMailUI); Wed, 29 Feb 2012 01:45:52 -0500 Message-Id: <8CEC4C4EA068E5C-9B4-6CF1@webmail-m055.sysops.aol.com> X-Originating-IP: [115.249.191.100] Date: Wed, 29 Feb 2012 01:45:52 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1330497952; bh=+CVNc4HrbyYvjSVWAKpCyxBmkQDlTFVOMGJ937hSiGQ=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=Cu/EVruj6CeBdPQb26yPRg7+9y6gsD4p1Czm1x/tf+8jMU0KkFyAXOcqUwGydBtme J3FBX7B3FxLi0+P8S0m/A8Ji8WOqHuNdodap7QXMstqCcKiEBcAuRhKEQeY3jHU0l7 7WGLwB6eKmu4n3oiwfmeyLsEH17KgzH99SLLl/c8= X-AOL-SCOLL-SCORE: 1:2:400164352:93952408 X-AOL-SCOLL-URL_COUNT: 1 x-aol-sid: 3039ac1d290b4f4dc9a06bfb Subject: [mpls] qn on RFC 6428 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, 29 Feb 2012 06:45:59 -0000 This is a multi-part message in MIME format. ----------MB_8CEC4C4EA33C8DB_9B4_1B98D_webmail-m055.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" HI Dave,Greg, John & others- What's the response for the following query on RFC 6428: Re: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between= RFC 6371 and draft-ietf-mpls-rosetta-stone, I'm interested in knowing about " explicit linkage between the type of the = monitored bi-directional LSP (co-routed or associated) and the number of ME= s associated with the LSP in RFC 6428 " Thanks ! /bala ----------MB_8CEC4C4EA33C8DB_9B4_1B98D_webmail-m055.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
HI Dave,Greg, John & others-

What's the response for the following query on RFC 6428:


I'm interested in knowing about "  explicit = linkage between the type of the monitored bi-directional LSP (co-routed or = associated)  and the n= umber of MEs associated with the LSP in RFC 6428  "


Thanks !

/bala

 ----------MB_8CEC4C4EA33C8DB_9B4_1B98D_webmail-m055.sysops.aol.com-- From julien.meuric@orange.com Wed Feb 29 02:04: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 14C9921F8803; Wed, 29 Feb 2012 02:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=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 I0T0ewi309-L; Wed, 29 Feb 2012 02:04:13 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A621F87FF; Wed, 29 Feb 2012 02:04:12 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D9E31E307A7; Wed, 29 Feb 2012 11:05:12 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id D04D3E302B6; Wed, 29 Feb 2012 11:05:12 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 11:04:11 +0100 Received: from [10.193.71.161] ([10.193.71.161]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 11:04:11 +0100 Message-ID: <4F4DF81A.3010801@orange.com> Date: Wed, 29 Feb 2012 11:04:10 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org References: <20120206.202719.2135711079242187783.harai@nict.go.jp> In-Reply-To: <20120206.202719.2135711079242187783.harai@nict.go.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Feb 2012 10:04:11.0533 (UTC) FILETIME=[7BF3B3D0:01CCF6C9] Cc: iPOP2012-tpc-sec@pilab.jp Subject: Re: [mpls] iPOP2012 Call for Presentation (extended deadline: Feb 29) 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, 29 Feb 2012 10:04:14 -0000 Hi IETF-ers. The extended deadline of iPOP CfP is today: this is your very last chance to submit a proposal to the 2012 edition of iPOP. Best regards, Julien Le 06/02/2012 12:27, Hiroaki Harai a écrit : > (Apologies if you received multiple copies of this message.) > > Dear CCAMP, PCE and MPLS subscribers, > > Please find iPOP2012 Call for Presentation. The deadline for > submitting presentation proposal (1-page abstract) is February 15th, > 2012. > > Best regards, > Hiroaki Harai > TPC Co-Chair for iPOP 2012 > > > --------------------------------------------------------------------- > Call for Presentation > > 8th International Conference on IP + Optical Network (iPOP 2012) > May 31 - June 1, 2012 > Hiyoshi Campus, Keio University, Yokohama-shi, Kanagawa, Japan > http://www.pilab.jp/ipop2012/ > > The conference is intended to share among the industry and the academia, > the knowledge, new findings, and experience on the state-of-the art of > IP and optical networking technologies. It features technical sessions > and planned exhibitions. The opportunity to participate is open to all. > > Important Dates: > Submission deadline of one-page abstract: February 15, 2012 > Notification of acceptance: March 30, 2012 > Submission deadline of final presentation slides: April 20, 2012 > > The Technical Program Committee for iPOP 2012 is soliciting presentation > proposals for this conference. Protocol design, experiment, theory, > implementation, and operational experiences are solicited. > The topics of the conference will include but not be limited to the following: > > * Photonic Network for NxGN and NwGN > * Multi-layer network (MLN) / Multi-region network (MRN) > * Inter-area/Inter-AS network > * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, > Impairment management > * GMPLS/ASON technologies > * GMPLS Network management, OA&M > * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet > transport technologies > * Path Computation Element (PCE), Traffic engineering > * Application with high-bandwidth demand > * L1VPN, Bandwidth on Demand, and Photonic Grid > * MPLS and Ethernet networking for Inter-data center connectivity for cloud > computing > * Carrier Ethernet and MPLS-TP for backhauling > * Testbed, field trial > > > If you wish to submit a topic for consideration, please send an Extended > Abstracts of 400 words and a maximum of 1 page, including figures and > diagrams, speaker’s name, affiliation, and contact information > to the Technical Program Committee at ipop2012-CFP@pilab.jp. > Please see http://www.pilab.jp/ipop2012/ for more details. > > Kind regards, > Hiroaki Harai, Julien Meuric, Eiji Oki > iPOP 2012 TPC Co-Chairs > > -------------------------------------------------------------------- > > From david.i.allan@ericsson.com Wed Feb 29 08:57: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 C3FE421F874C for ; Wed, 29 Feb 2012 08:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 pVr6z603RhzI for ; Wed, 29 Feb 2012 08:57:44 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3F621F874A for ; Wed, 29 Feb 2012 08:57:44 -0800 (PST) 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 q1TGvb5k015172; Wed, 29 Feb 2012 10:57:38 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.46]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 29 Feb 2012 11:57:31 -0500 From: David Allan I To: Bala Venkata , "mpls@ietf.org" Date: Wed, 29 Feb 2012 11:57:31 -0500 Thread-Topic: [mpls] qn on RFC 6428 Thread-Index: Acz2rdDECauyp87rT8umPsXyMIDdOQATGOyg Message-ID: <60C093A41B5E45409A19D42CF7786DFD522CFE5FB9@EUSAACMS0703.eamcs.ericsson.se> References: <8CEC4C4EA068E5C-9B4-6CF1@webmail-m055.sysops.aol.com> In-Reply-To: <8CEC4C4EA068E5C-9B4-6CF1@webmail-m055.sysops.aol.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_60C093A41B5E45409A19D42CF7786DFD522CFE5FB9EUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [mpls] qn on RFC 6428 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, 29 Feb 2012 16:57:44 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD522CFE5FB9EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bala: Yes, unfortunately that follow on question dropped through at last my crack= s. Apologies! When we did RFC 6371 we were in uncharted territory w.r.t. associated bi-di= rectional. We characterized the MEG for an associated bi-directional LSP as= two MEs as they potentially did not share any MIPs in common, nor did the = paths fate share, two way RTT measurements did not really tell you much etc= . So pretty much all the impact was w.r.t on-demand FM, and PM and it was h= ard to consider it to be a single bi-directional ME. The MEG was not really= a closed system except for the proactive FM case. Pretty much none of that impacted 6428 as CC/CV is purely MEP-MEP proactive= FM so no representation was made. And it is not obvious to me that we need= to do anything now. I hope this helps Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Bal= a Venkata Sent: Tuesday, February 28, 2012 10:46 PM To: mpls@ietf.org Subject: [mpls] qn on RFC 6428 HI Dave,Greg, John & others- What's the response for the following query on RFC 6428: Re: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between= RFC 6371 and draft-ietf-mpls-rosetta-stone, I'm interested in knowing about " explicit linkage between the type of the= monitored bi-directional LSP (co-routed or associated) and the number of = MEs associated with the LSP in RFC 6428 " Thanks ! /bala --_000_60C093A41B5E45409A19D42CF7786DFD522CFE5FB9EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Bala:
 
Yes, unfortunately that follow on question = dropped=20 through at last my cracks. Apologies!
 
When we did RFC 6371 we were in uncharted t= erritory=20 w.r.t. associated bi-directional. We characterized the MEG for an=20 associated bi-directional LSP as two MEs as they potentially did not s= hare=20 any MIPs in common, nor did the paths fate share, two way RTT measurements = did=20 not really tell you much etc. So pretty much all the impact was w.r.t on-de= mand=20 FM, and PM and it was hard to consider it to be a single bi-directional ME.= The=20 MEG was not really a closed system except for the proactive FM=20 case.
 
Pretty much none of that impacted 6428 as CC/CV is pu= rely=20 MEP-MEP proactive FM so no representation was made. And it is not obvious t= o me=20 that we need to do anything now.
 
I hope this helps
Dave
 
 

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Bala Venkata
Sent:= =20 Tuesday, February 28, 2012 10:46 PM
To:=20 mpls@ietf.org
Subject: [mpls] qn on RFC 6428

HI Dave,Greg, John & others-

What's the response for the following query on RFC 6428:

Re: [mpls] Maintenance Entity definition for MPLS-TP: a discre= pancy=20 between RFC 6371 and draft-ietf-mpls-rosetta-stone,=20

I'm=20 interested in knowing about "  explicit linkage = between=20 the type of the monitored bi-directional LSP (co-routed or=20 associated)  and the number of= MEs=20 associated with the LSP in RFC 6428  "


Thanks !

/bala

 --_000_60C093A41B5E45409A19D42CF7786DFD522CFE5FB9EUSAACMS0703e_-- From mustapha.aissaoui@alcatel-lucent.com Wed Feb 29 12:35: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 C94E521E803B for ; Wed, 29 Feb 2012 12:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.89 X-Spam-Level: X-Spam-Status: No, score=-8.89 tagged_above=-999 required=5 tests=[AWL=1.708, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YduunKta4e9D for ; Wed, 29 Feb 2012 12:35:51 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AF61D21E801C for ; Wed, 29 Feb 2012 12:35:51 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q1TKZhwd013032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Feb 2012 14:35:43 -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 q1TKZhQh027701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Feb 2012 14:35:43 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 29 Feb 2012 14:35:42 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: Lizhong Jin Date: Wed, 29 Feb 2012 14:35:41 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: AczlR+hW13amK3+CRWyR54u0xbDYrAAYcWrgBF3bmbA= Message-ID: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD55FDAD9@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD55FDAD9@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_5DF53972F7E9134782DCE51624466FE50AD575E18EUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 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, 29 Feb 2012 20:35:53 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD575E18EUSNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, I actually think that we would need to define a new one which will accomoda= te an IPv6 /128 address. Otherwise, targeted LDP sessions in a all-IPv6 net= work will not be possible. I cannot see that operators will start maintaini= ng a mapping of some global non routable LSR-id value to an IPv6 loopback i= nterface on each router in the network. Mustapha. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ais= saoui, 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-i= d need not be an IP address. Most implementations will actually populate th= e field with a /32 address in IPv4 and thus If necessary we could define a = new format to allow the use of /128 IPv6 addresses. 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 with= out IPv6 adjacency, and only use one adjacency for LDP session in dual-stac= k network. LDP capability is per node capability, not per interface capabil= ity. But for LDP to choose the correct downstream session and output interf= ace for each FEC, it should also check if the output interface is LDP enabl= ed 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 32= bit 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 impac= ts. > > Thanks, > Pranjal > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e 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 th= e 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_5DF53972F7E9134782DCE51624466FE50AD575E18EUSNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lizhong,
I=20 actually 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 network w= ill=20 not be possible. I cannot see that operators will start maintaining a mappi= ng of=20 some global non routable LSR-id value to an IPv6 loopback interfa= ce on=20 each router in the network.
 
Mustapha.
From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha=20 (Mustapha)
Sent: Tuesday, February 07, 2012 10:12 AM
To:=20 Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com
Cc:=20 mpls@ietf.org
Subject: Re: [mpls] Comments on=20 draft-ietf-mpls-ldp-ipv6-06

Lizhong,
the existing LSR-id will do the job and should be supported si= nce the=20 LSR-id need not be an IP address. Most implementations will actua= lly=20 populate the field with a /32 address in IPv4 and thus If necessary we coul= d=20 define a new format to allow the use of /128=20 IPv6 addresses.
 
Mustapha.

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


Hi,
I wonder if it is feasible to use LDP capability to adver= tise=20 IPv6 FEC without IPv6 adjacency, and only use one adjacency for LDP session= in=20 dual-stack network. LDP capability is per node capability, not per interfac= e=20 capability. But for LDP to choose the correct downstream session and output= =20 interface for each FEC, it should also check if the output interface is LDP= =20 enabled or not. The link adjacency could be used to assist such kind of=20 checking.

However, IMO, it = is=20 valuable 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 version num= ber=20 to identify IPv6 LSR-ID. Or we use different 32bit LSR-ID for IPv6 with IPv= 4,=20 but I prefer new format of LSR-ID.

Regards
Lizho= ng=20


>=20 ----------------------------------------------------------------------
&= gt;=20
> Message: 1
> Date: Tue, 7 Feb 2012 05:28:21 +0530
> Fr= om:=20 "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
&g= t;=20 To: Vishwas Manral <vishwas.ietf@gmail.com>
> Cc: "Aissaoui,=20 Mustapha \(Mustapha\)"
>  =20  <mustapha.aissaoui@alcatel-lucent.com>,  =20 "mpls@ietf.org"
>    <mpls@ietf.org>
> Subject:= Re:=20 [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> Message-ID:
>= =20  =20  <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.
= >=20 alcatel-lucent.com>
>    
> Content-Type: text/pla= in;=20 charset=3D"us-ascii"
>
> I would rather for complete separatio= n with=20 multiple lsr-id because
> having separate link adjacencies does not= =20 really solved any problem.
> Since hello adjacencies are associated w= ith a=20 link, still fate
> sharing would continue over the single ldp/tcp se= ssion=20 for IPV4 and IPV6.
> Having IPV4 and IPV6 specific hello adjacencies = over=20 a link would
> only decide whether such a link is to be programmed f= or=20 IPV4 or IPV6
> egress traffic but I see it as overkill and unnecessar= y=20 scalability impacts.
>
> Thanks,
> Pranjal
>=20 
--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--_000_5DF53972F7E9134782DCE51624466FE50AD575E18EUSNAVSXCHMBSC_-- From lizhong.jin@zte.com.cn Wed Feb 29 16:58: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 1A60321F866B for ; Wed, 29 Feb 2012 16:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.279 X-Spam-Level: X-Spam-Status: No, score=-101.279 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 T+s+8mFc-P8L for ; Wed, 29 Feb 2012 16:58:27 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7520321F8661 for ; Wed, 29 Feb 2012 16:58:26 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 52373806486374; Thu, 1 Mar 2012 08:51:56 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 35739.4734952721; Thu, 1 Mar 2012 08:58:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q210wDNt021590; Thu, 1 Mar 2012 08:58:13 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> To: "Aissaoui, Mustapha (Mustapha)" 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 08:57:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-01 08:58:15, Serialize complete at 2012-03-01 08:58:15 Content-Type: multipart/alternative; boundary="=_alternative 00055499482579B4_=" X-MAIL: mse02.zte.com.cn q210wDNt021590 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 00:58:28 -0000 This is a multipart message in MIME format. --=_alternative 00055499482579B4_= Content-Type: text/plain; charset="US-ASCII" 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 00055499482579B4_= Content-Type: text/html; charset="US-ASCII"
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 00055499482579B4_=-- From pranjal.dutta@alcatel-lucent.com Wed Feb 29 17:03: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 631B121E8038 for ; Wed, 29 Feb 2012 17:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.207 X-Spam-Level: X-Spam-Status: No, score=-9.207 tagged_above=-999 required=5 tests=[AWL=0.791, 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 OxXvK4C68Sbg for ; Wed, 29 Feb 2012 17:03:50 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0E45D21E801F for ; Wed, 29 Feb 2012 17:03:49 -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 q2113hPW020049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Feb 2012 19:03:45 -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 q2113gPj031228 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Mar 2012 06:33:42 +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, 1 Mar 2012 06:33:42 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Lizhong Jin , "Aissaoui, Mustapha (Mustapha)" Date: Thu, 1 Mar 2012 06:33:39 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3Rmr46Q9pXArHRna3rM3nm6qzvQAAEFGw 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_C584046466ED224CA92C1BC3313B963E09F00CA6A9INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 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 01:03:51 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CA6A9INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. --_000_C584046466ED224CA92C1BC3313B963E09F00CA6A9INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 with a local ipv4 interface address in th= e system.

 

Thanks,

Pranjal

 

From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Wednesday, February 29= , 2012 4:57 PM
To: Aissaoui, Mustapha (Must= apha)
Cc: mpls@ietf.org; Dutta, Pr= anjal 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 o= ut in my first email.

Thanks
Lizhong
 

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> 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 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@INBAN= SXCHMBSA3.in.
> > 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 system.

--_000_C584046466ED224CA92C1BC3313B963E09F00CA6A9INBANSXCHMBSA_-- From vishwas.ietf@gmail.com Wed Feb 29 17:11: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 63AFC21E803A for ; Wed, 29 Feb 2012 17:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=-0.480, 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 elmiwHfUhrOI for ; Wed, 29 Feb 2012 17:11:29 -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 E77DA21E8072 for ; Wed, 29 Feb 2012 17:11:14 -0800 (PST) Received: by obbeh20 with SMTP id eh20so90341obb.31 for ; Wed, 29 Feb 2012 17:11:14 -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 d8mr1144989obc.36.1330564274628 (num_hops = 1); Wed, 29 Feb 2012 17:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2BbC1HEpwZyWyFJ3+GxuO4J00IPbzJUDBif0DFV/nM4=; b=vz6UzHKbSXFtjyvN/l4offZ0RmPFcm7p4zq4/jtphZPS26+yWXQ4dg7DOzMHnbZdZX STmQG1ICkO63QScLQ4f/4Vg+OumBSRFehfEZXDEnnBMCIsYnQR0OYiKAZd5kY/GG6Pvt KNdY5qcleDmMUISEx+JQibZt6NhhYRM7V22DQ= MIME-Version: 1.0 Received: by 10.182.13.8 with SMTP id d8mr973669obc.36.1330564274525; Wed, 29 Feb 2012 17:11:14 -0800 (PST) Received: by 10.182.165.1 with HTTP; Wed, 29 Feb 2012 17:11:13 -0800 (PST) In-Reply-To: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Date: Wed, 29 Feb 2012 17:11:13 -0800 Message-ID: From: Vishwas Manral To: "Dutta, Pranjal K (Pranjal)" Content-Type: multipart/alternative; boundary=f46d04448163ef14f104ba242214 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 01:11:31 -0000 --f46d04448163ef14f104ba242214 Content-Type: text/plain; charset=ISO-8859-1 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="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.**** > > --f46d04448163ef14f104ba242214 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have co= me after last call are:

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

The second c= ould lead to changes required in both OSPF and IS-IS, as well because the n= ew LSR ID would then need to be exchanged. We could treat it as an enhancem= ent instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 20= 12 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 th= e system.

=A0

Thanks,<= /font>

Pranjal<= /font>

=A0

From: Lizhong Ji= n [mailto:lizhong= .jin@zte.com.cn]
Sent: Wednesday, February 29= , 2012 4:57 PM
To: Aissaoui, Mustapha (Must= apha)
Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vi= shwas.ietf@gmail.com


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

=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.

Thanks
Lizhong
=A0

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> w= rote 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-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.
> =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@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)" <p= ranjal.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&= quot;
> > =A0 =A0<mpl= s@ietf.org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> > =A0 =A0<C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMB= SA3.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.


--f46d04448163ef14f104ba242214-- From rajiva@cisco.com Wed Feb 29 19:28: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 EEF0D21E803E for ; Wed, 29 Feb 2012 19:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.337 X-Spam-Level: X-Spam-Status: No, score=-9.337 tagged_above=-999 required=5 tests=[AWL=1.262, 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 JjVQN2a3Sy6H for ; Wed, 29 Feb 2012 19:27:59 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AD5B921E801E for ; Wed, 29 Feb 2012 19:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=25879; q=dns/txt; s=iport; t=1330572478; x=1331782078; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tIzMNjS2RsOpP2VbxS4jGzAgM8s+hzkzF+RFg/GfCBs=; b=cbDAdtKPuUdNeluOcaSAm8zlBoo2vqSUAb+txISUPpL3uoBNtNFeUExw XEqbPCkMHVAZQgLnt23Asq3n+GEHL4KCn92fT3twXSkIfQOGiNEuJeWb/ TcyIPVjfO5MayqGvRSIgdtlxjcrUNlbNNviTE0Qj1n59kGwnj3YIeYdOB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMzrTk+tJV2Y/2dsb2JhbABDtAiBB4F6AQEBAwEBAQEPAQcWCi0HBAcFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggBEgeHYgULoFIBlyeMegIDAwUDAgEBBAEDAQEEAQEBBgQEAj2FZgEKAwcEBhgCgkljBIhPoACBNQc X-IronPort-AV: E=Sophos;i="4.73,507,1325462400"; d="scan'208";a="62854935" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 01 Mar 2012 03:27:58 +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 q213RveY032328; Thu, 1 Mar 2012 03:27:57 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); Wed, 29 Feb 2012 21:27:57 -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: Wed, 29 Feb 2012 21:27:56 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@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: Aczi9gKBKcjtZosmRQi3iyzlmOQNUwB6XhAAAwQ3gdA= References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" , "Shane Amante" X-OriginalArrivalTime: 01 Mar 2012 03:27:57.0918 (UTC) FILETIME=[4C2FAFE0:01CCF75B] 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 03:28:01 -0000 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. 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.=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 // > > 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. > > 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.=20 =09 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. :) =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. 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. > > 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.=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. It is MAY. :) It was changed to MAY based on the exhaustive discussion on mailing list in 2011 for us to move forward.=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. 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. 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. // > > 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.=20 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,=20 http://www.ietf.org/proceedings/80/minutes/mpls.txt 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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Regards, > Mustapha. >=20 > -----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 >=20 > Mustapha, >=20 > 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). >=20 > 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? >=20 > 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. >=20 > 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. >=20 > Just my $0.02, >=20 > -shane >=20 >=20 >=20 > 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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From mtinka@globaltransit.net Wed Feb 29 20:03: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 62B2A21F85AE for ; Wed, 29 Feb 2012 20:03:17 -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 p+LkHwcSGv69 for ; Wed, 29 Feb 2012 20:03:16 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id 82DE521F85AD for ; Wed, 29 Feb 2012 20:03:16 -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 1S2xEX-0006FW-BZ; Thu, 01 Mar 2012 12:03:13 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Thu, 1 Mar 2012 12:03:12 +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> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1579915.7vM19PmYyE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203011203.12854.mtinka@globaltransit.net> Cc: "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: Thu, 01 Mar 2012 04:03:17 -0000 --nextPart1579915.7vM19PmYyE Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, March 01, 2012 11:27:56 AM Rajiv Asati (rajiva)=20 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=20 rather this isn't the default. If a default needs to be=20 implemented by a vendor, then AF separation would be my=20 preference. However, I'd support including knobs to allow operators to=20 consolidate, if they so wished. Mark. --nextPart1579915.7vM19PmYyE 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) iQIcBAABAgAGBQJPTvUAAAoJEGcZuYTeKm+GWIcP/0W1JMg6r1gqk2T1c36c+/2P NF7TWguywK+2BbjI3/he+boyiooBehqoZFonjnFwC+jMpzLSu4ELG7hBnXH/a0Ge YYtgIZ9dRS4OUJdSdibAyk8LGNzMhi3wiPDyjqqLWEOG8D+yXIoFezgJ8YRoirO3 5FYcf+qAfpxziOEMVZgfFhqus8PgBmzhOCUSdQ46p5emcluGGJPOyR9oXpUGZh5e 16YTJVb703XdNsx01lDAOK7LcOvpBFOQdSKj3N8q3xGh7fmj4IcSOe0pRMoovSQf FiY4Y5Pmam/4IldaW+gJq647S8KE77qvJMaOs83nHgfPRBovawbiGO//HdfXK9Ff SzZxiQgSwa5Kl/CKyIYBbuaV2UEkyI3iwOq6w7TBdxwqbJ5teK5fBlyGtpEcDMfQ EqDpJfUiowT4R7rwkkdHUqOeH6dY93kDZBdGSzeYTE04H9h1yOA2hXZK4LSjbo0K sWUh/Rix1FqMESkBdcHgO4G4jdQDw2l0tsXyfhQ5ngvx1FSL/EWUYw5XZv0xBmwZ 4B9qyQGNDk/WqbIvw8fsZVm8UqzKdEVjCY++lHXAlSVc8aZpVAvYAARvTzhfnIM6 g/C60lfl8vzpRGiiiv8J3h45Ze4El1+X+Agz3ONY3M2hgHP+HGz5ex55GlVEZhIX vlDrThJk/91P6IhD/NSU =XITm -----END PGP SIGNATURE----- --nextPart1579915.7vM19PmYyE-- From skraza@cisco.com Wed Feb 29 20:39: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 B481521E8021 for ; Wed, 29 Feb 2012 20:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.236 X-Spam-Level: X-Spam-Status: No, score=-8.236 tagged_above=-999 required=5 tests=[AWL=0.367, 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 n40zqsPnqRJe for ; Wed, 29 Feb 2012 20:39:46 -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 794C521E801E for ; Wed, 29 Feb 2012 20:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=19968; q=dns/txt; s=iport; t=1330576786; x=1331786386; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=4i0IWY7BC1m/w2MjvktwBDRM166eQMvskLppGwGBK24=; b=YpMtqOUnmbyVeO7Ew36C99sSUWaVdiITjP4s5Xnyh+J3K70TZS13A1pC Km3fQqzU0qjzpO+YD+Ud6XN8ss45Cr5EJsjdNkSgLZBYj+HxP4XR24ZnE 6L0zdj0OR58FuLzthDtys9KgT/N/Gd5LtWAvEgrTkm3x/bDug27GAMJzH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFACz9Tk+tJXG//2dsb2JhbAA6BwOCP6AqkB5vgQeBegEBAQMBAQEBDwEqGBEICwUNAQgRAwEBAQEnKAYfCQgBAQQOBSKHYgULmj4BnwaJF2IJgngHAQIDAgkBBAQDAQoBQQ4BBoRdFAYDBQRPARgEAgEHEQEJgyMEiBwzjHCLGod1gT4 X-IronPort-AV: E=Sophos;i="4.73,507,1325462400"; d="scan'208,217";a="62882594" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 01 Mar 2012 04:39:45 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q214djSB022777; Thu, 1 Mar 2012 04:39:45 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 22:39:45 -0600 Received: from 10.86.245.210 ([10.86.245.210]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Mar 2012 04:39:45 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 29 Feb 2012 23:39:44 -0500 From: Kamran Raza To: Vishwas Manral , "Dutta, Pranjal K (Pranjal)" Message-ID: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3ZVLPXkGCI1J0x0KRiPd99Trm7Q== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3413403584_3387620" X-OriginalArrivalTime: 01 Mar 2012 04:39:45.0612 (UTC) FILETIME=[53C5A0C0:01CCF765] 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 04:39:49 -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_3413403584_3387620 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 unique i= d and need not be routable, though most implementations currently populate it with /32 loopback address. Let=B9s not carry forward a wrong notion/usage. 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 protoco= l change =8B i.e. we should bump up LDP protocol version in LDP PDU header for this, and possibly define new format for =B3LDP Identifier=B2 in the context of new LDP protocol version. My 2 cents.=20 On 12-02-29 8:11 PM, "Vishwas Manral" wrote: > 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. >> =A0 >> Thanks, >> Pranjal >> =A0 >>=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 >> =A0 >>=20 >> Hi Mustapha,=20 >> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I poin= ted >> out in my first email. >>=20 >> Thanks=20 >> Lizhong=20 >> =A0=20 >>=20 >> "Aissaoui, Mustapha (Mustapha)" w= rote >> 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. >>> > =A0=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 >>> > =A0=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\)" >>>> > > =A0 =A0, =A0 "mpls@ietf.org" >>>> > > =A0 =A0 >>>> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> > > Message-ID: >>>> > > =A0 =A0>>> > > alcatel-lucent.com > >>>> > > =A0 =A0 >>>> > > Content-Type: text/plain; charset=3D"us-ascii" >>>> > >=20 >>>> > > I would rather for complete separation with multiple lsr-id becaus= e >>>> > > having separate link adjacencies does not really solved any proble= m. >>>> > > Since hello adjacencies are associated with a link, still fate >>>> > > sharing would continue over the single ldp/tcp session for IPV4 an= d >>>> 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 IP= V6 >>>> > > egress traffic but I see it as overkill and unnecessary scalabilit= y >>>> 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 >>=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_3413403584_3387620 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
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.

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 Identifie= r” 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:

<= 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> wro= te:
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.
=A0
Thanks,
Pranjal
=A0

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 (Pra= njal); vishwas.ietf@gmail.com

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

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

Thanks
Lizhong
=A0

"Aissaoui, Mustapha= (Mustapha)" <mustaph= a.aissaoui@alcatel-lucent.com> 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.
> =A0
> 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 IPv6ad= dresses.
> =A0
> 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; 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.i= etf@gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> > =A0 =A0<mustapha.ai= ssaoui@alcatel-lucent.com>, =A0 "mpls@ietf= .org"
> > =A0 =A0<mpls@ietf.org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> > =A0 =A0<C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.
> > alcatel-lucent.com <http:/= /alcatel-lucent.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 sy= stem.



___________= ____________________________________
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_3413403584_3387620--

Yes, adjacency specific capability exchange in hello would be right approach for IPV4 + IPV6 and need to exten= d the work of RFC 5561.

The ldp-ipv6 draft should change the t= ext on multiple adjacency behaviour on dual stack and should refer to the per adjacency specific ldp

capabilities.=

 

Thanks,

Pranjal

 

From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Tuesday, February 07, = 2012 6:25 PM
To: Dutta, Pranjal K (Pranjal)
Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); Kamran Raza; vishwas.ietf@gmail.com
Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 


Pranjal,
See inline below.

Thanks
Lizhong
 

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

> Hi,
>      
> Thanks,
> Pranjal
>      
>
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Kamran Raza
> Sent: Monday, February 06, 2012 8:50 PM=
> To: Lizhong Jin; D= utta, Pranjal K (Pranjal); vishwas.ietf@gmail.com;<= br> > Aissaoui, Mustapha= (Mustapha)
> Cc: mpls@ietf.org<= /st1:PersonName>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>  
> Hi Lizhong,
>
> Using single adj [ and just checking local int= erface enabling for
> given AF + capabilities ] will not suffice/wor= k because:
>
>  1. LDP capabilities= are advertised on peer/session level and do not
> correspond to adj capabilities. >  2. An LSR must not = be forwarding MPLS on an interface unless/until
> it has got an MPLS adj on it <= font face=3D"Courier New">– extending the same to address
> families, an LSR must not forward MPLS v6 on a= n interface unless it
> has got MPLS v6 adj on it. [ Single adj will n= ot convey us remote
> node’s interface capabi= lity for given AF, and it will be incorrect
> to forward 6 MPLS labelled traffic on it unles= s we know that remote
> intf is v6 MPLS enabled ]
>
>  My 2 cents. > -- Kamran
>
> On 12-02-06 10:22 PM, "Lizhong Jin" <lizhong.jin@zte.com.cn> wrote:
>
> Hi,
> I wonder if it is feasible to use LDP capabili= ty 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 interfac= e for each FEC, it
> should also check if the output interface is L= DP enabled or not. The
> link adjacency could be used to assist such ki= nd of checking.
>
> [Kamran]:
>
> 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: "D= utta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
> > To: Vishwas M= anral <vishwas.ietf@gmail.com>
> > Cc: "Ais= saoui, 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 separation wi= th multiple lsr-id because
> > having separate link adjacencies does not really solved any problem.
> > Since hello adjacencies are associated wi= th a link, still fate
> > sharing would continue over the single ld= p/tcp session for IPV4 and IPV6.
> > Having IPV4 and IPV6 specific hello adjac= encies 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 a= nd unnecessary scalability impacts.
> >
> > Thanks,
> > Pranjal
> >
>
> ______________________________________________= _
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
> --
> Syed Kamran Raza
> Technical Leader, SPRSG IOS-XR Routing (MPLS)<= /font>
> Cisco Systems, Inc.,
> K= anata, ON, K2K 3E8= , Canada
> Ph: +1 (613) 254-4520
> http://www.cisco.com
> 

&nb=
sp;
-------------------=
-------------------------------------
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<=
font
face=3D"Courier New"> 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<=
font
face=3D"Courier New"> message has been scanned for viruses and Spam by ZTE Anti-Spam system.