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

From: Lizhong Jin<[email-masked]>
Date: Thu, 1 Mar 2012 16:45:44 +0800

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

Regards
Lizhong

> Thanks,
> Vishwas

> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <
> [email-masked]> 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:[email-masked]] 
> Sent: Wednesday, February 29, 2012 4:57 PM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: [email-masked]; Dutta, Pranjal K (Pranjal); [email-masked]
> 
> 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)" <[email-masked]
> > 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: [email-masked] [mailto:[email-masked]] On Behalf 
Of 
> > Aissaoui, Mustapha (Mustapha)
> > Sent: Tuesday, February 07, 2012 10:12 AM
> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked]
> > Cc: [email-masked]
> > 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:[email-masked]] 
> > Sent: Monday, February 06, 2012 10:23 PM
> > To: Dutta, Pranjal K (Pranjal); [email-masked]; Aissaoui, 
> > Mustapha (Mustapha)
> > Cc: [email-masked]
> > 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)" 
<[email-masked]>
> > > To: Vishwas Manral <[email-masked]>
> > > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> > >    <[email-masked]>,   "[email-masked]"
> > >    <[email-masked]>
> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > > Message-ID:
> > >    <[email-masked].
> > > 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.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 1 Mar 2012 08:51:13 -0600

that is correct. We do not want to change the meaning of LSR-ID. We just want it to be able to accomodate a global unique ID of the size of an IPv6 address.

There will certainly be other additions to make the protocol support separate sessions and as such bumping the protocol version might be required.

Mustapha.

________________________________
From: Kamran Raza [mailto:[email-masked]]
Sent: Wednesday, February 29, 2012 11:40 PM
To: Vishwas Manral; Dutta, Pranjal K (Pranjal)
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

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

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

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <[email-masked]> wrote:

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) <[email-masked]> 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

________________________________

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)" <[email-masked]> wrote 2012/03/01 04:35:41:

> From: [email-masked] [mailto:[email-masked]] On Behalf Of

> necessary we could define a new format to allow the use of /128 IPv6addresses.
>
> Mustapha.
>

> > From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
> > alcatel-lucent.com <http://alcatel-lucent.com> >
> >
> > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > egress traffic but I see it as overkill and unnecessary scalability impacts.
> >
> > Thanks,
> > Pranjal
> >
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

________________________________
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

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

---

From: Shane Amante <[email-masked]>
Date: Thu, 1 Mar 2012 08:45:27 -0700

Kamran,

> Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and need not be routable, though most implementat…

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

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

-shane

---

From: Kamran Raza <[email-masked]>
Date: Thu, 01 Mar 2012 12:57:44 -0500

Shane,

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

-- Kamran

On 12-03-01 10:45 AM, "Shane Amante" <[email-masked]> wrote:

>> Firstly, I don¹t agree that LSR Id be made IPv6 (address) based and/or
>> route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id
>> and need not be routable, though most implementations currently populate it
>> with /32 loopback address. Let¹s not carry forward a wrong notion/usage.
> 
> Although, in theory, the LSR-ID "need not be routable", I can say that in the
> networks I operate it is *always* routable. From a simple troubleshooting PoV,
> it's extremely easy to:
> b) use traceroute and/or a routing table to learn the _topological_ location
> of the /32 (4-octet) LSR-ID in the network ...
> 
> In summary, there is a tremendous amount of operational value in the 4-Byte
> LSR-ID actually be announced/routed in a network's IGP -- let us not
> underestimate that. All I'm saying is, let's not go out of our way to try to
> make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical
> reasons.
> 
> -shane
> 
> 
>> Secondly, If there is a need to define new ³LDP Identifier² in order to
>> establish/maintain a separate session for IPv6 AF, this should be a protocol
>> change ‹ i.e. we should bump up LDP protocol version in LDP PDU header for
>> this, and possibly define new format for ³LDP Identifier² in the context of
>> new LDP protocol version.
>> 
>> My 2 cents. 
>> 
>> On 12-02-29 8:11 PM, "Vishwas Manral" <[email-masked]
>> <x-msg://1083/[email-masked]> > wrote:
>> 
>>> 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)
>>> <[email-masked]
>>> <x-msg://1083/[email-masked]> > 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
>>>>  
>>>> 
>>>> 
>>>> Cc: [email-masked] <x-msg://1083/[email-masked]> ; Dutta, Pranjal K
>>>> (Pranjal); [email-masked] <x-msg://1083/[email-masked]>
>>>> 
>>>> <x-msg://1083/[email-masked]> > wrote 2012/03/01
>>>> 04:35:41:
>>>> 
>>>>> > Hi Lizhong,
>>>>> > From: [email-masked] <x-msg://1083/[email-masked]>
>>>>> [mailto:[email-masked]] On Behalf Of
>>>>> <x-msg://1083/[email-masked]>
>>>>> > Cc: [email-masked] <x-msg://1083/[email-masked]>
>>>>> > To: Dutta, Pranjal K (Pranjal); [email-masked]
>>>>> <x-msg://1083/[email-masked]> ; Aissaoui,
>>>>> > Mustapha (Mustapha)
>>>>> > Cc: [email-masked] <x-msg://1083/[email-masked]>
>>>>>> > > From: "Dutta, Pranjal K (Pranjal)" <[email-masked]
>>>>>> <x-msg://1083/[email-masked]> >
>>>>>> > > To: Vishwas Manral <[email-masked]
>>>>>> <x-msg://1083/[email-masked]> >
>>>>>> > >    <[email-masked]
>>>>>> <x-msg://1083/[email-masked]> >,   "[email-masked]
>>>>>> <x-msg://1083/[email-masked]> "
>>>>>> > >    <[email-masked] <x-msg://1083/[email-masked]> >
>>>>>> > >    <[email-masked]
>>>>>> 
<x-msg://1083/[email-masked]>>>>>>
n> .
>>>>>> > > alcatel-lucent.com <http://alcatel-lucent.com>
>>>>>> <http://alcatel-lucent.com <http://alcatel-lucent.com/> > >
>>>>>> > >    
>>> [email-masked] <x-msg://1083/[email-masked]>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 1 Mar 2012 23:33:51 +0530

Hi Kamran,
                   We were mentioning about multi-lsr sessions for fate separation anyway.  Having 16 byte long LSR-ID would automatically fall back to multi-lsr sessions in dual stack situations.

Thanks,
Pranjal

________________________________
From: Kamran Raza [mailto:[email-masked]]
Sent: Thursday, March 01, 2012 9:58 AM
To: Shane Amante
Cc: Vishwas Manral; Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Shane,

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

-- Kamran

On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote:
Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and need not be routable, though most implementations currently populate it with /32 loopback address. Let's not carry forward a wrong notion/usage.

-shane

Secondly, If there is a need to define new "LDP Identifier" in order to establish/maintain a separate session for IPv6 AF, this should be a protocol change - i.e. we should bump up LDP protocol version in LDP PDU header for this, and possibly define new format for "LDP Identifier" in the context of new LDP protocol version.

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <[email-masked] <x-msg://1083/[email-masked]> > wrote:
Hi Lizhong/ Pranjal/ Mustapha,

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <[email-masked] <x-msg://1083/[email-masked]> > 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

Cc: [email-masked] <x-msg://1083/[email-masked]> ; Dutta, Pranjal K (Pranjal); [email-masked] <x-msg://1083/[email-masked]>

Hi Mustapha,

Thanks
Lizhong

"Aissaoui, Mustapha (Mustapha)" <[email-masked] <x-msg://1083/[email-masked]> > wrote 2012/03/01 04:35:41:

> From: [email-masked] <x-msg://1083/[email-masked]>  [mailto:[email-masked]] On Behalf Of
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked] <x-msg://1083/[email-masked]>

> To: Dutta, Pranjal K (Pranjal); [email-masked] <x-msg://1083/[email-masked]> ; Aissaoui,
> Mustapha (Mustapha)

> > From: "Dutta, Pranjal K (Pranjal)" <[email-masked] <x-msg://1083/[email-masked]> >
> > To: Vishwas Manral <[email-masked] <x-msg://1083/[email-masked]> >
> >    <[email-masked] <x-msg://1083/[email-masked]> >,   "[email-masked] <x-msg://1083/[email-masked]> "
> >    <[email-masked] <x-msg://1083/[email-masked]> .
> > alcatel-lucent.com <http://alcatel-lucent.com>  <http://alcatel-lucent.com <http://alcatel-lucent.com/> > >
> >

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 1 Mar 2012 12:07:23 -0600

I agree. Based on the discussion & agreement, we will proceed with the
document as it-is.

It is worth noting that this (LSR ID) really relates to router-id, which
is used by not only LDP, but also other protocols (e.g. BGP, OSPF). Of
course, each protocol could use the common router-id or a different one.
Strictly speaking, all these protocols define router-id to be not
routable and leverage the same 4-octet number for IPv6 as well.

For ex, One could look at RFC 6286, which updated the base BGP spec
RFC4271, to ensure the usage of 4-octet as the BGP ID in the context of
IPv6.

There is no benefit & reason to change LSR ID definition 32-bit to
128-bit for LDP without considering the bigger picture having other
protocols in the network. This specific issue has been visited before
and closed. 

Cheers,
Rajiv

> -----Original Message-----
Of
> Lizhong Jin
> Sent: Thursday, March 01, 2012 3:46 AM
> To: Vishwas Manral
> Cc: Aissaoui, Mustapha (Mustapha); [email-masked]
> [Lizhong] agree, but as Kamran pointed out also in another email, it
is not
> necessary to flood LSR-ID in routing protocol, the transport address
in hello
> message is required to be flooded.
> 
> Regards
> Lizhong
> 
> >
> > Thanks,
> > Vishwas
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 1 Mar 2012 23:38:32 +0530

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

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Thursday, March 01, 2012 7:45 AM
To: Kamran Raza
Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Kamran,

-shane

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <[email-masked]<x-msg://1083/[email-masked]>> wrote:

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<x-msg://1083/[email-masked]>> wrote:

Thanks,
Pranjal

Cc: [email-masked]<x-msg://1083/[email-masked]>; Dutta, Pranjal K (Pranjal); [email-masked]<x-msg://1083/[email-masked]>

Hi Mustapha,

Thanks
Lizhong

"Aissaoui, Mustapha (Mustapha)" <[email-masked]<x-msg://1083/[email-masked]>> wrote 2012/03/01 04:35:41:

> From: [email-masked]<x-msg://1083/[email-masked]> [mailto:[email-masked]] On Behalf Of
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked]<x-msg://1083/[email-masked]>
> Cc: [email-masked]<x-msg://1083/[email-masked]>

> To: Dutta, Pranjal K (Pranjal); [email-masked]<x-msg://1083/[email-masked]>; Aissaoui,
> Mustapha (Mustapha)
> Cc: [email-masked]<x-msg://1083/[email-masked]>

> > From: "Dutta, Pranjal K (Pranjal)" <[email-masked]<x-msg://1083/[email-masked]>>
> > To: Vishwas Manral <[email-masked]<x-msg://1083/[email-masked]>>
> >    <[email-masked]<x-msg://1083/[email-masked]>>,   "[email-masked]<x-msg://1083/[email-masked]>"
> >    <[email-masked]<x-msg://1083/[email-masked]>>
> >    <[email-masked]<x-msg://1083/[email-masked]>.
> > alcatel-lucent.com<http://alcatel-lucent.com> <http://alcatel-lucent.com<http://alcatel-lucent.com/>> >
> >

________________________________
_______________________________________________
mpls mailing list
[email-masked]<x-msg://1083/[email-masked]>
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<http://www.cisco.com/>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "t.petch" <[email-masked]>
Date: Thu, 1 Mar 2012 18:16:51 +0100

----- Original Message -----
From: "Shane Amante" <[email-masked]>
To: "Kamran Raza" <[email-masked]>
Cc: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>;
"Lizhong Jin" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 01, 2012 4:45 PM

Kamran,

On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote:
> Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/or
route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and
need not be routable, though most implementations currently populate it with /32
loopback address. Let’s not carry forward a wrong notion/usage.

<tp>
Had much experience lately of keying in a 128-bit IPv6 address with pinpoint
accuracy in order to ping a device?  Um, it stinks.

Protocols like OSPF that decided that a 32 bit router ID was perfect for all
address families got it absolutely right, IMO.  The better organisations I know
make a point of making the router ID an impossible address, so that regardless
of context, it is immediately apparent whether a dotted decimal number is a
routable address or an ID.

Tom Petch

</tp>

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

-shane

> Secondly, If there is a need to define new “LDP Identifier” in order to
establish/maintain a separate session for IPv6 AF, this should be a protocol
change — i.e. we should bump up LDP protocol version in LDP PDU header for this,
and possibly define new format for “LDP Identifier” in the context of new LDP
protocol version.
>> 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?
IPv6addresses.
IPV6.
system.

--------------------------------------------------------------------------------

---

From: Kamran Raza <[email-masked]>
Date: Thu, 01 Mar 2012 13:20:16 -0500

>> Esp. for T-LDP hellos we would always like to match destination IP of hello
packets to match 4 byte LSR-ID,

Just a quick comment on the above statement:

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

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

Thx.
-- Kamran

On 12-03-01 1:08 PM, "Dutta, Pranjal K (Pranjal)"
<[email-masked]> wrote:

> Esp. for T-LDP hellos we would always like to match destination IP of hello
> packets to match 4 byte LSR-ID, so same is applicable for IPV6.
> TCP Transport address is an after affect  T-LDP hellos should be sent to the
> correct IPV6 address first before TCP transport address comes into play.
>  
> 
> 
> 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
>  
> 
>  
> 
> 
> Cc: [email-masked] <x-msg://1083/[email-masked]> ; Dutta, Pranjal K (Pranjal);
> [email-masked] <x-msg://1083/[email-masked]>
> 
>>> <x-msg://1083/[email-masked]>
.
>>> > > sharing would continue over the single ldp/tcp session for IPV4 and >>>
IPV6.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 1 Mar 2012 12:54:19 -0600

Having 4-octet LSR ID for IPv6 is good enough, IMO. 
AFAIK, It is good enough for BGP, OSPF etc.

One could look at RFC 6286, which updated the base BGP spec RFC4271, to
ensure the usage of 4-octet as the BGP ID in the context of IPv6.
One could also look at RFC5340 - OSPF for IPv6.

BGP RFC6286
//
      The BGP Identifier is a 4-octet, unsigned, non-zero integer that
      should be unique within an AS.  The value of the BGP Identifier
//

OSPF RFC5340
//
   o  OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the
      IPv4 size of 32 bits.  They can no longer be assigned as (IPv6)
      addresses.
//

   o  On all link types (e.g., broadcast, NBMA, point-to-point, etc.),
      neighbors are identified solely by their OSPF Router ID.  For all

   o  The neighbor's choice of Designated Router and Backup Designated
      Router is now encoded as an OSPF Router ID instead of an IP
      interface address.
//

Cheers,
Rajiv

Of
> Shane Amante
> Sent: Thursday, March 01, 2012 10:45 AM
> To: Kamran Raza (skraza)
> 	Firstly, I don't agree that LSR Id be made IPv6 (address) based
and/or
> need not be routable, though most implementations currently populate
it
> with /32 loopback address. Let's not carry forward a wrong
notion/usage.
> networks I operate it is *always* routable. From a simple
troubleshooting
> PoV, it's extremely easy to:
> In summary, there is a tremendous amount of operational value in the
4-
> Byte LSR-ID actually be announced/routed in a network's IGP -- let us
not
> 	Secondly, If there is a need to define new "LDP Identifier" in
order to
> change - i.e. we should bump up LDP protocol version in LDP PDU header
> for this, and possibly define new format for "LDP Identifier" in the
context of
> 	On 12-02-29 8:11 PM, "Vishwas Manral" <[email-masked]
<x-
> msg://1083/[email-masked]> > wrote:
> 
> 
> 
> 		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
> <[email-masked] <x-msg://1083/pranjal.dutta@alcatel-
> lucent.com> > wrote:
> 
> 
> 			Yes, I support that too. There would be network
> management issues with mapping of 4 byte LSR-ID to an IPV6 remote
> address.
> 			Most of the implementations I know off usually
maps
> 4 byte of the LSR-ID with a local ipv4 interface address in the
system.
> 			Cc: [email-masked] <x-msg://1083/[email-masked]> ;
> Dutta, Pranjal K (Pranjal); [email-masked] <x-
> msg://1083/[email-masked]>
> 
> 			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)"
> <[email-masked] <x-
> msg://1083/[email-masked]> > wrote 2012/03/01
> 04:35:41:
> 
> 			> Hi Lizhong,
> 			> I actually think that we would need to define
a new
> one which will
> 			> 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: [email-masked]
<x-msg://1083/mpls-
> [email-masked]>  [mailto:[email-masked]] On Behalf Of
> 			> To: Lizhong Jin; Dutta, Pranjal K (Pranjal);
> 			> 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
> 			> 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:[email-masked]]
> 			> To: Dutta, Pranjal K (Pranjal);
> [email-masked] <x-msg://1083/[email-masked]> ;
Aissaoui,
> 			> 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
> 			> 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.
> 			> Or we use different 32bit LSR-ID for IPv6 with
IPv4,
> but I prefer
------------------------------------------------------------
> ----------
> <[email-masked] <x-msg://1083/pranjal.dutta@alcatel-
> lucent.com> >
<x-
> msg://1083/[email-masked]> >
> 			> >    <[email-masked] <x-
> msg://1083/[email-masked]> >,   "[email-masked]
<x-
> msg://1083/[email-masked]> "
> 			> >    <[email-masked]
<x-msg://1083/[email-masked]>
> >
> 			> > Subject: Re: [mpls] Comments on
draft-ietf-mpls-
> ldp-ipv6-06
> <x-
> msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCH
> MBSA3.in> .
> 			> > alcatel-lucent.com
<http://alcatel-lucent.com
> <http://alcatel-lucent.com/> > >
> 			> >
> 			> > 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
> 			> 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
> 			> 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
> 	http://www.cisco.com <http://www.cisco.com/>
> 
> 
> 
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 1 Mar 2012 13:17:42 -0600

Pranjal,

> packets to match 4 byte LSR-ID, so same is applicable for IPV6.

Really !

Could you please point to the right RFC5036 section that says the above?

Cheers,
Rajiv

Of
> Dutta, Pranjal K (Pranjal)
> Sent: Thursday, March 01, 2012 1:09 PM
> To: Shane Amante; Kamran Raza (skraza)
> TCP Transport address is an after affect - T-LDP hellos should be sent
to the
Of
and/or
it
notion/usage.
troubleshooting
4-
not
> Secondly, If there is a need to define new "LDP Identifier" in order
to
context of
> On 12-02-29 8:11 PM, "Vishwas Manral" <[email-masked] <x-
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
> 
LSR-ID
> with a local ipv4 interface address in the system.
(Pranjal);
> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I
pointed out
> in my first email.
<x-
> > To: Dutta, Pranjal K (Pranjal); [email-masked] <x-
> msg://1083/[email-masked]> ; Aissaoui,
> > Mustapha (Mustapha)
> > > From: "Dutta, Pranjal K (Pranjal)"
<[email-masked] <x-
> msg://1083/[email-masked]> >
<x-
> > > alcatel-lucent.com <http://alcatel-lucent.com <http://alcatel-
> lucent.com/> > >
> > >
scalability impacts.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 2 Mar 2012 03:11:45 +0530

I never claimed that it is stated by RFC 5036! Did I?
It's what we "like" to do in most cases..whereas cases do exists where it is not so (Kamran's last reply). 

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Thursday, March 01, 2012 11:18 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante; Kamran Raza (skraza)
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Really !

Cheers,
Rajiv

Of
to the
Of
and/or
it
notion/usage.
troubleshooting
4-
not
to
context of
well
it
LSR-ID
(Pranjal);
pointed out
<x-
<x-
scalability impacts.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 2 Mar 2012 04:39:10 +0530

Kamran,

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

Cheers,
Pranjal

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kamran Raza
Sent: Thursday, March 01, 2012 10:20 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>> Esp. for T-LDP hellos we would always like to match destination IP of hello packets to match 4 byte LSR-ID,

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

Thx.
-- Kamran

On 12-03-01 1:08 PM, "Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote:
Esp. for T-LDP hellos we would always like to match destination IP of hello packets to match 4 byte LSR-ID, so same is applicable for IPV6.
TCP Transport address is an after affect - T-LDP hellos should be sent to the correct IPV6 address first before TCP transport address comes into play.

Kamran,

-shane

My 2 cents.

Thanks,
Vishwas

Thanks,
Pranjal

Hi Mustapha,

Thanks
Lizhong

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 1 Mar 2012 21:36:31 -0600

Pranjal,

Thanks for confirming. We are in sync.

Cheers,
Rajiv

> From: Dutta, Pranjal K (Pranjal)
[mailto:[email-masked]]
> Sent: Thursday, March 01, 2012 4:42 PM
> To: Rajiv Asati (rajiva); Shane Amante; Kamran Raza (skraza)
> It's what we "like" to do in most cases..whereas cases do exists where
it is
> not so (Kamran's last reply).
> 
> > Esp. for T-LDP hellos we would always like to match destination IP
of
> hello
> > Esp. for T-LDP hellos we would always like to match destination IP
of
> hello
> > Although, in theory, the LSR-ID "need not be routable", I can say
that
> in the
> > underestimate that. All I'm saying is, let's not go out of our way
to
> try to
<x-msg://1083/pranjal.dutta@alcatel-
> > Yes, I support that too. There would be network management issues
with
> > <x-msg://1083/[email-masked]> > wrote
[email-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 1 Mar 2012 21:43:04 -0600

Hi Tom,

Appreciate you sharing your view. Pls see inline,

> make a point of making the router ID an impossible address, so that
> regardless of context, it is immediately apparent whether a dotted
decimal 
> number is a routable address or an ID.

Well put. The same is true for BGP as well.

> accuracy in order to ping a device?  Um, it stinks.

It certainly does. Not to mention the usage of shift : after every 3-4
numerals. :-)
All of sudden, pinging the devices via their hostnames (even if having
lower and upper cases) seems easier.  

Cheers,
Rajiv

Of
> t.petch
> Sent: Thursday, March 01, 2012 12:17 PM
and/or
it
> with /32
> loopback address. Let's not carry forward a wrong notion/usage.
> 
troubleshooting
4-
> Byte
to
> for this,
> and possibly define new format for "LDP Identifier" in the context of
new
it
> as an
LSR-
> ID
> >>> 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,
[email-masked]
> >>> > RFC5036, we may need new LDP version number to identify IPv6
LSR-
> ID.
> >>> > > egress traffic but I see it as overkill and unnecessary
scalability
> impacts.
------------------------------------------------------------------------
--------

---

From: Shane Amante <[email-masked]>
Date: Thu, 1 Mar 2012 22:44:59 -0700

Tom,

On Mar 1, 2012, at 10:16 AM, t.petch wrote:
> accuracy in order to ping a device?

Yes.

> Um, it stinks.

Um, not really. Again, we're talking about Loopback IP addresses used as "Router ID's" in protocols. Specifically, here's a real world example difference between an IPv4 /32 and IPv6 /128 Loopback assigned to a live, production box (slightly obsfucated to protect the innocent):

interface Loopback0
 ip address A.BB.CCC.16 255.255.255.255
 ipv6 address 2001:XXXX::Y:Z/128

... in reality, it's a difference of 3-digits.  OTOH, if the IPv4 address was assigned out of traditional IPv4 Class C space, (192/3), then the difference would have been a single digit.  (OK, yes, I'll concede that if someone is not fortunate enough or properly planned ahead, then they could end up with a substantially larger number of digits ... but, that's typically not the case given the ease at which nearly anyone can get a PIv6 block today).

> routable address or an ID.

The larger point I'm trying to bring attention to is that, shockingly, the world really is moving toward IPv6. Yay! At some point in the future (certainly not next year, maybe not in 3 - 5 years), we're all going to want to run IPv6-only networks to reduce OpEx. So, the question I ask is: what then?
a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I can transport IPv4 "Router ID's" around my network? Or,
b) Will we have to settle for IPv4-mapped IPv6 addresses, just for the purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the operational reasons I outlined in my previous e-mail?  (If so, then I think it's a moot point if you're typing a IPv4-mapped IPv6 address or a Native IPv6 address for a Router ID -- they're likely roughly of the same length).

Either approach seems a bit "kludgy" to me. Then again, I'm willing to be told that I'm the one being the purist. Perhaps, (b) is "the answer" and I just hadn't gotten the memo. :-)

Regardless, I'm suggesting that if we're looking at making a change to any protocol to support IPv6, let's make sure we briefly, but carefully, look at what the roadmap holds for the future and weigh the costs of making a single change to LDP, now, to future-proof LDP (and, other protocols) for IPv6, rather than make yet more changes down the road ...

Just my $0.02,

-shane

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 2 Mar 2012 00:02:51 -0600

Hi Shane,

Thankfully, neither approaches are embraced/recommended/considered.

> a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I
can
> transport IPv4 "Router ID's" around my network? Or,

No. 

Router-ID is no longer a routable entity in IPv6 networks. Please refer
to BGP (RFC6286) & OSPF (RFC5340).
In fact, OSPF (RFC5340) explicitly prohibits Router ID to be any IPv6
address.

BGP RFC6286
//

OSPF RFC5340
//

> b) Will we have to settle for IPv4-mapped IPv6 addresses, just for the
> purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the
> operational reasons I outlined in my previous e-mail?

No.

It wouldn't make any sense, nor would it help. 
v4-mapped v6 address is still a v6 address, after all and it wouldn't do
any good for 32-bit router-id.

Cheers,
Rajiv

Of
> Shane Amante
> Sent: Friday, March 02, 2012 12:45 AM
> To: t.petch
and/or
it
> > Although, in theory, the LSR-ID "need not be routable", I can say
that in the
troubleshooting
> Um, not really. Again, we're talking about Loopback IP addresses used
as
> "Router ID's" in protocols. Specifically, here's a real world example
difference
> between an IPv4 /32 and IPv6 /128 Loopback assigned to a live,
production
> box (slightly obsfucated to protect the innocent):
> 
> interface Loopback0
> ... in reality, it's a difference of 3-digits.  OTOH, if the IPv4
address was
> assigned out of traditional IPv4 Class C space, (192/3), then the
difference
> would have been a single digit.  (OK, yes, I'll concede that if
someone is not
> fortunate enough or properly planned ahead, then they could end up
with a
> substantially larger number of digits ... but, that's typically not
the case given
> the ease at which nearly anyone can get a PIv6 block today).
> 
> 
> > address families got it absolutely right, IMO.  The better
organisations I
> know
> regardless
> > of context, it is immediately apparent whether a dotted decimal
number is
> a
> The larger point I'm trying to bring attention to is that, shockingly,
the world
> really is moving toward IPv6. Yay! At some point in the future
(certainly not
> next year, maybe not in 3 - 5 years), we're all going to want to run
IPv6-only
> networks to reduce OpEx. So, the question I ask is: what then?
> a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I
can
> transport IPv4 "Router ID's" around my network? Or,
> b) Will we have to settle for IPv4-mapped IPv6 addresses, just for the
> purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the
> operational reasons I outlined in my previous e-mail?  (If so, then I
think it's a
> moot point if you're typing a IPv4-mapped IPv6 address or a Native
IPv6
> address for a Router ID -- they're likely roughly of the same length).
> 
> Either approach seems a bit "kludgy" to me. Then again, I'm willing to
be told
> that I'm the one being the purist. Perhaps, (b) is "the answer" and I
just
> hadn't gotten the memo. :-)
> 
> Regardless, I'm suggesting that if we're looking at making a change to
any
> protocol to support IPv6, let's make sure we briefly, but carefully,
look at
> what the roadmap holds for the future and weigh the costs of making a
> single change to LDP, now, to future-proof LDP (and, other protocols)
for
> IPv6, rather than make yet more changes down the road ...
> 
> Just my $0.02,
> 
> -shane
> 
> 
> > Tom Petch
> >
> > </tp>
> >
> >
> >
> >
> >
4-
> > underestimate that. All I'm saying is, let's not go out of our way
to try to
order to
> > and possibly define new format for "LDP Identifier" in the context
of new
> it as an
LSR-
> >>>> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as
I
> >>>>> accomodate an IPv6 /128 address. Otherwise, targeted LDP
sessions
[email-masked]
LSR-
scalability

---

From: Shane Amante <[email-masked]>
Date: Fri, 2 Mar 2012 00:02:08 -0700

Rajiv,

>      IPv4 size of 32 bits.  They can no longer be assigned as (IPv6)

Yes, I heard you before.  Thanks, got that.

So, please tell me how I'm supposed to ping/traceroute to this 32-bit "Router ID" in this new IPv6-only world, just like I do today in IPv4 today, to verify reachability?  Usually, this is one of the first steps in troubleshooting a problem.  I'm curious if we've gotten lazy by assuming dual-stack v4 + v6 will "always be there", so I can just use v4 to ping/traceroute to a 32-bit Router ID ... but, what happens when v4 is no longer there any more?

> any good for 32-bit router-id.

FWIW, I was suggesting another imperfect "hack" wrt (b). Specifically, a protocol could use/exchange/etc. a 32-bit ROUTER_ID on-the-wire; however, "out-of-band" I assign a IPv4-mapped IPv6 address to a Loopback interface on a router and inject it into my "IPv6-only" IGP in order to preserve my ability to see it in the topology (in the routing table), and simultaneously am able to ping/traceroute to it to ensure that the Loopback interface is "alive".  But, this is a kludge, because now I have to keep the ROUTER_ID in sync with the configuration of IPv4-mapped IPv6 address on a Loopback interface ... 

-shane

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 2 Mar 2012 22:46:46 +0530

Hi Kamran,
                      Further some comments below.
Thanks,
Pranjal

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

Thx.
-- Kamran

Kamran,

-shane

My 2 cents.

Thanks,
Vishwas

Thanks,
Pranjal

Hi Mustapha,

Thanks
Lizhong

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 2 Mar 2012 23:52:22 +0530

Hi Viswas,
                     We raised one more point earlier on the following clause in the draft.

Section 6.2

   As outlined in section 2.5.5 of RFC5036, this draft describes that

   if an LSR has a dual-stack interface, which is enabled with both

   IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and

   IPv6 LDP Link Hellos and must separately maintain the Hello

   adjacency for IPv4 and IPv6 on that interface.

     This ensures successful labeled IPv4 and labeled IPv6 traffic

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

     peering using the appropriate transport on a multi-access

     interface (even if there are IPv4-only, IPv6-only and dual-stack

     LSRs connected to that multi-access interface).

The draft mandates that two separate hello adjacencies should be maintained on dual-stack - one for IPV4 and another for IPV6. We don't see any benefit or technical reason of running two separate adjacencies.

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

2.      This clause mandates that a transit network that is carrying IPV6 LSPs must provision IPv6 interfaces.  It is not mandatory that the transport network itself be IPV6 in order to carry IPV6 traffic over its tunnels. This is a very narrow interpretation of section 2.5.5 in  RFC 5036. It's not necessary that an IPV6 FEC should be resolved by an IPV6 only route next-hop. The hello adjacency can still be over an IPV4 link and IPV6 prefix can still be resolved by an IPV4 route next-hop. It's not necessary that source of hellos be IPv6 or transport address of TCP session be ipv6.

3.      This clause has unnecessary scalability implications. We do run very large number of LDP adjacencies/sessions (e.g 10K) in mobility backhauls or similar deployments. This clause requires to run 20K hello adjacencies which has scalability implications. On theory there may not much difference between 10K and 20K but in real implementations there is. If we allow separation of sessions for fate separation of IPV4 and IPV6 then it would become 40K adjacencies.

We can limit to only one hello adjacency per interface yet address the dual stack issue. A graceful solution is to come up with a notion of LDP adjacency specific capabilities (similar to LDP capabilities that applies to entire sessions) that would benefit multiple purposes. For example, we have multiple ECMP Links between neighboring LSRs A and B as shows below.

                                   +----------------L1------------------+

                                   |                                             |

                                  A ----------------L2----------------- B

                                   |                                             |

                                   +----------------L3------------------+

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

Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3 are IPv6 capable.

Then hellos exchanged over link would advertise capabilities as below:

L1 would carry capabilities - Ipv4 + Mcast

      L2 would carry capabilities - ipv4 + ipv6 + Mcast

      L3 would carry capabilities - ipv4 + ipv6

>From an implementer/system designer's point of view I would think single hello adjacency with per adjacency capabilities would be right approach.

Thanks,

Pranjal

________________________________
From: Vishwas Manral [mailto:[email-masked]]
Sent: Wednesday, February 29, 2012 5:11 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Thanks,
Vishwas
On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 29, 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: [email-masked]<mailto:[email-masked]>; Dutta, Pranjal K (Pranjal); [email-masked]<mailto:[email-masked]>

Hi Mustapha,

Thanks
Lizhong

"Aissaoui, Mustapha (Mustapha)" <[email-masked]<mailto:[email-masked]>> wrote 2012/03/01 04:35:41:

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>

> From: Lizhong Jin [mailto:[email-masked]<mailto:[email-masked]>]
> To: Dutta, Pranjal K (Pranjal); [email-masked]<mailto:[email-masked]>; Aissaoui,
> Mustapha (Mustapha)
> Cc: [email-masked]<mailto:[email-masked]>

> > From: "Dutta, Pranjal K (Pranjal)" <[email-masked]<mailto:[email-masked]>>
> > To: Vishwas Manral <[email-masked]<mailto:[email-masked]>>
> >    <[email-masked]<mailto:[email-masked]>>,   "[email-masked]<mailto:[email-masked]>"
> >    <[email-masked]<mailto:[email-masked]>>
> > alcatel-lucent.com<http://alcatel-lucent.com>>
> >

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sat, 3 Mar 2012 00:56:18 +0530

Well, I am not sure if we are in sync. You have heard enough examples from operators on this. 

Thanks,
Pranjal

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Thursday, March 01, 2012 7:37 PM
To: Dutta, Pranjal K (Pranjal); Shane Amante; Kamran Raza (skraza)
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Cheers,
Rajiv

it is
of
of
that
to
with
[email-masked]
> > > RFC5036, we may need new LDP version number to identify IPv6
LSR-ID.

---

From: Mark Tinka <[email-masked]>
Date: Sat, 3 Mar 2012 13:09:30 +0800

On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K 
(Pranjal) wrote:

> >From an implementer/system designer's point of view I
> >would think single hello adjacency with per adjacency
> >capabilities would be right approach.

Pranjal, I appreciate that from a vendor perspective, 
implementing it this way would make sense for large scale 
deployments.

However, for some operators who may be using BGP or RSVP to 
signal or nest a large number of LSP's, we would like to 
have the option of choosing a discrete separation of IPv4 
and IPv6 adjacencies for LDP.

If there are operators who aren't going to be looking at 
scaling that many LSP's anytime in their network, they might 
still prefer to eliminate adjacency fate-sharing.

I would propose that vendors implement both options, 
allowing operators to choose (via CLI) which method they 
would like to deploy in the field. There are many operators 
out there who maintain separate BGP transport and policy 
sessions for IPv4 and IPv6 AF's to protect themselves 
against the problems fate-sharing could bring. This is why 
some of us prefer to make our lives harder by going native, 
dual-stack rather than 6PE :-).

So while I won't disagree with your opinion on using a 
single adjacency for both AF's for scaling purposes, I would 
certainly like to have the option to choose which method 
suits me best in the wild.

Mark.

---

From: Shane Amante <[email-masked]>
Date: Sat, 3 Mar 2012 00:34:24 -0700

Mark,

I completely agree with all of your comments below. I too would (strongly) prefer the option to allow operators to choose (via CLI) whether to:
a) use separate transport to ensure there is no fate-sharing of IPv4 + IPv6; or,
b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, other AF's) on a single session, for scale reasons.

-shane

---

From: Lizhong Jin<[email-masked]>
Date: Mon, 5 Mar 2012 14:38:57 +0800

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

Regards
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 
2012/03/03 02:22:22:

> The draft mandates that two separate hello adjacencies should be 
> maintained on dual-stack – one for IPV4 and another for IPV6. We 
> don’t see any benefit or technical reason of running two separate 
> adjacencies. 
> 
> 1.      First of all, doing so does not provide fate separation any 
> way. Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. 

> 
> 2.      This clause mandates that a transit network that is carrying
> IPV6 LSPs must provision IPv6 interfaces.  It is not mandatory that 
> the transport network itself be IPV6 in order to carry IPV6 traffic 
> over its tunnels. This is a very narrow interpretation of section 2.
> 5.5 in  RFC 5036. It’s not necessary that an IPV6 FEC should be 
> resolved by an IPV6 only route next-hop. The hello adjacency can 
> still be over an IPV4 link and IPV6 prefix can still be resolved by 
> an IPV4 route next-hop. It’s not necessary that source of hellos be 
> IPv6 or transport address of TCP session be ipv6.
> 
> 3.      This clause has unnecessary scalability implications. We do 
> run very large number of LDP adjacencies/sessions (e.g 10K) in 
> mobility backhauls or similar deployments. This clause requires to 
> run 20K hello adjacencies which has scalability implications. On 
> theory there may not much difference between 10K and 20K but in real
> implementations there is. If we allow separation of sessions for 
> fate separation of IPV4 and IPV6 then it would become 40K adjacencies.
> 
> We can limit to only one hello adjacency per interface yet address 
> the dual stack issue. A graceful solution is to come up with a 
> notion of LDP adjacency specific capabilities (similar to LDP 
> capabilities that applies to entire sessions) that would benefit 
> multiple purposes. For example, we have multiple ECMP Links between 
> neighboring LSRs A and B as shows below.
> 
> The hello adjacencies over L1, L2 and L3 are IP4 interfaces are 
> using either IPV4 OR ipv6 addresses but not both.
> 
> L1 would carry capabilities – Ipv4 + Mcast
>       L2 would carry capabilities – ipv4 + ipv6 + Mcast
>       L3 would carry capabilities – ipv4 + ipv6 
> 
> 
> From an implementer/system designer’s point of view I would think 
> single hello adjacency with per adjacency capabilities would be 
> right approach. 
> 
> Thanks,
> Pranjal 
> 
> 
Of 
IPV6.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 6 Mar 2012 00:01:23 +0530

Hi Mark,
         Please refer my responses inline.
Thanks,
Pranjal

-----Original Message-----
From: Mark Tinka [mailto:[email-masked]] 
Sent: Friday, March 02, 2012 9:10 PM
To: [email-masked]
Cc: Dutta, Pranjal K (Pranjal); Vishwas Manral; Aissaoui, Mustapha (Mustapha); Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

<Pranjal> I think we are confusing two different things. Having separate hello adjacency over an interface as mandated in ldp-ipv6 draft **DOES NOT** give you fate separation. Still both IPV4 and IPV6 FECs would fate-share same LDP session.

We are in fact saying that fate separation is desirable but for that we need 
separation of **sessions** and NOT hello adjacencies. If you follow the ldp-ipv6 draft of separate adjacencies for IPV4 and IPV6 still all IPV4 and IPV6 
FECs would be fate sharing a **single** LDP sessions.

The ldp-ipv6 draft makes it **mandatory** that dual stack interface MUST 
Have two separate hello adjacencies. This does not make any sense from 
practical stand point and rather raises many open questions keeping in view of existing applicability/capabilities of LDP. IP6 FEC next-hop resolution algorithms does not mandate running hello adjacency with an ipv6 next-hop. FEC capabilities are decoupled from the address family used in hello adjacencies. 

Just to give an example. Let's take the WG item on mLdp in-band signaling
draft below. 

http://tools.ietf.org/html/draft-ietf-mpls-mldp-in-band-signaling-05

This draft defines in-band signaling of multicast (S,G)s top set-up the LDP Multicast tunnels for the respective S,Gs. If we look at section 3 it has IPV4 as well as IPV6 specific multicast LSPs. If ldp-ipv6 draft mandates running separate adjacencies on dual stack then the question would be - where is the placement of those LSP types w.r.t dual hello adjacencies **mandated** by ldp-ipv6? 

The WG has decided to move to LDP capabilities (RFC 5561) to advertise various capabilities of a single LDP session. Various extensions has been done further based on that. For example, mLdp Spec (RFC 6388) defines capabilities for various multicast fec types (Refer to section 2.1) over an ldp sessions. mLdp has been shipped and is deployed. Now are we saying we 
Should be running **separate** hello adjacencies per FEC type over a **single** Interface with **same** peering LSR? 

There is another WG item that introduces IP and PW FEC Capability.

http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-01

Then why the fundamental shift for IPV6 unicast FECs alone? I have scouted the archive on all discussions occurred in the past on ldp-ipv6 yet hasn't seen a strong technical basis why it is MUST for IPV6 FECs to take a radically different approach. 

In ldp-ipv6 draft, the proposal of running separate ipv4 and ipv6 hello adjacencies yet fate sharing **same** session to signal dual stack capabilities is a fundamental shift from the capability based approaches already adopted by the WG. IPV6 is just another FEC element type. I have seen puritanical references like "OSPF does so", "BGP does so" in some discussions in this list but that does not provide enough technical basis in the context of LDP. There has to be a single/consistent approach 

To satisfy your requirement for fate separation of IPV4 and IPV6 FECs, we need to work out a separate spec on running "multi-lsr" **sessions** between two peering systems - as an extension to RFC 5036.  Such method can not only useful for IPV4 and IPV6 FEC separation but for other types as well. For example, it can also provide an option for fate separation of PW FECs (L2 Over lay) from the transport FECs (IPV4, IPV6, Multicast).   

</Pranjal>

<Pranjal> As I mentioned above separation of ipv4 and ipv6 hello adjacencies does not provide fate separation. I guess what you are mentioning about 
Separation of IPV4 and IPV6 FECs over two separate LDP sessions between 
two peering systems which can be achieved by running multi-lsr sessions.

<\Pranjal> 

<Pranjal>
   
I think what you are looking for knob to toggle fate sharing and fate separation of IPV4 and IPV6 FECs. For this we need a knob whether we 
Single LSR peering or multi-lsr peering. This is different from separation 
Of ipv4 and ipv6 hello adjacencies. In LDP, hello adjacencies are discovery protocols and does not have "tight" coupling with various FEC types existent in LDP.  We can satisfy both fate-shared and fate-separation requirements using single hello adjacency (with per adjacency capabilities) associated with a remote lsr-id.

</Pranjal>

Mark.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 6 Mar 2012 00:14:47 +0530

Hi Shane,
          Yes, two separate LDP sessions are required for fate separation of ipv4 and ipv6 fecs. 

Separation of ipv4 and ipv6 hello adjacencies are not required to satisfy 
a) and b). Both can be achieved with single hello adjacency per interface
per peering lsr-id with adjacency specific capabilities.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Friday, March 02, 2012 11:34 PM
To: [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Mark,

-shane

---

From: Shane Amante <[email-masked]>
Date: Mon, 5 Mar 2012 23:13:06 -0700

Hi Pranjal,

> per peering lsr-id with adjacency specific capabilities.

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

With respect to LDP Hellos, you're suggesting that operators run either IPv4-only Hello's or IPv6-only Hello's, (never both at the same time), but through either one can discover the "(IPv4|IPv6) transport capabilities" of a LDP peer and, based on that, establish an IPv4 and/or IPv6 LDP session.  Correct?

-shane

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 6 Mar 2012 23:57:39 +0530

Hi Shane,
          Yes, that's correct. We can run either ipv4 hellos or ipv6 hellos and operator can choose whichever is best,  based upon the operational needs. Since the src ip addresses used by hello packets are not coupled with FEC types so single hello can advertise various FEC capabilities. 

         If we run multiple ldp sessions between peering systems for fate separation of ipv4 and ipv6 then there can be two separate hello adjacencies over a single interface (each one associated with separate sessions) but in that case the LSR-IDS used would be different (we need to work for an extension of RFC 5036).

Thanks,
Pranjal

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Monday, March 05, 2012 10:13 PM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]; Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Pranjal,

On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote:
> a) and b). Both can be achieved with single hello adjacency per 
> interface per peering lsr-id with adjacency specific capabilities.

-shane

> Of Shane Amante
>>>> From an implementer/system designer's point of view I would think 
>> Pranjal, I appreciate that from a vendor perspective, implementing it 
>> this way would make sense for large scale deployments.
>> 
>> However, for some operators who may be using BGP or RSVP to signal or 
>> nest a large number of LSP's, we would like to have the option of 
>> choosing a discrete separation of IPv4 and IPv6 adjacencies for LDP.
>> 
>> If there are operators who aren't going to be looking at scaling that 
>> many LSP's anytime in their network, they might still prefer to 
>> eliminate adjacency fate-sharing.
>> 
>> I would propose that vendors implement both options, allowing 
>> operators to choose (via CLI) which method they would like to deploy 
>> in the field. There are many operators out there who maintain 
>> separate BGP transport and policy sessions for IPv4 and IPv6 AF's to 
>> protect themselves against the problems fate-sharing could bring. 
>> This is why some of us prefer to make our lives harder by going 
>> native, dual-stack rather than 6PE :-).
>> 
>> So while I won't disagree with your opinion on using a single 
>> adjacency for both AF's for scaling purposes, I would certainly like 
>> to have the option to choose which method suits me best in the wild.
>> 
>> Mark.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 2 Mar 2012 13:26:00 -0600

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

Mustapha.

Sent: Friday, March 02, 2012 1:22 PM

Hi Viswas,

Section 6.2

                                   |                                             |

                                   |                                             |

Thanks,

Pranjal

Thanks,
Vishwas

Thanks,
Pranjal

Hi Mustapha,

Thanks
Lizhong

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sat, 3 Mar 2012 01:07:18 +0530

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

Thanks,
Pranjal

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

Mustapha.

Section 6.2

                                   |                                             |

                                   |                                             |

Thanks,

Pranjal

Thanks,
Vishwas

Thanks,
Pranjal

Hi Mustapha,

Thanks
Lizhong

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 2 Mar 2012 11:49:57 -0800

Hi Pranjal/ Mustapha,

This has been discussed a few times over already.

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

Thanks,
Vishwas

On Fri, Mar 2, 2012 at 11:37 AM, Dutta, Pranjal K (Pranjal) <
[email-masked]> wrote:

> **
>
> Yes, this approach would lead to all “kludgy” implementations. Due to race
> conditions between UDP based LDP hellos and TCP connections (since they are
> independent channels) it may lead to states of continually flapping
> sessions.****
>
> ** **
>
> Thanks,****
>
> Pranjal****
>
> ** **
>  ------------------------------
>
> *From:* **Aissaoui, Mustapha** (Mustapha)
> *Sent:* Friday, March 02, 2012 11:26 AM
> *To:* **Dutta, Pranjal K** (Pranjal); **Vishwas Manral**
> *Cc:* Lizhong Jin; [email-masked]
> **
> *Subject:* RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> ****
>
>  ** **
>
> I also have an issue with the stability of such an implementation. The
> draft suggests in Section 6.1 - Transport connection establishment, that
> a TCP connection with IPv6 should be preferred to one with IPv4 if both
> IPv4 and IPv6 adjacencies exist. This means that if the IPv4 adjacency came
> up first and boot straps the IPv4 TCP connection, as soon as the IPv6 hello
> is established, we tear down the IPv4 TCP connection and signal the IPv6
> one. This of course is not acceptable. In RFC 5036 compliant
> implementations, when a new adjacency comes up to the same LSR-ID, we just
> associate it with the existing TCP connection which was bootstrapped by the
> first Hello adjacency.****
>
>  ****
>
> Mustapha.****
>
> ** **
>  ------------------------------
>
> *From:* **Dutta, Pranjal K** (Pranjal)
> *Sent:* Friday, March 02, 2012 1:22 PM
> *To:* **Vishwas Manral**
> *Cc:* Lizhong Jin; **Aissaoui, Mustapha** (Mustapha); [email-masked]**
> *Subject:* RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06****
>
> Hi Viswas,****
>
>                      We raised one more point earlier on the following
> clause in the draft.****
>
> ** **
>
> Section 6.2 ****
>
> ** **
>
>    As outlined in section 2.5.5 of RFC5036, this draft describes that****
>
>    if an LSR has a dual-stack interface, which is enabled with both****
>
>    IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and****
>
>    IPv6 LDP Link Hellos and must separately maintain the Hello****
>
>    adjacency for IPv4 and IPv6 on that interface.****
>
> ** **
>
>      This ensures successful labeled IPv4 and labeled IPv6 traffic****
>
>      forwarding on a dual-stacked interface, as well as successful LDP****
>
>      peering using the appropriate transport on a multi-access****
>
>      interface (even if there are IPv4-only, IPv6-only and dual-stack****
>
>      LSRs connected to that multi-access interface).****
>
> ** **
>
> ** **
>
> The draft mandates that two separate hello adjacencies should be maintained on dual-stack – one for IPV4 and another for IPV6. We don’t see any benefit or technical reason of running two separate adjacencies.  ****
>
> ** **
>
> **1.                     **First of all, doing so does not provide fate separation any way. Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. ****
>
> ** **
>
> **2.                     **This clause mandates that a transit network that is carrying IPV6 LSPs must provision IPv6 interfaces.  It is not mandatory that the transport network itself be IPV6 in order to carry IPV6 traffic over its tunnels. This is a very narrow interpretation of section 2.5.5 in  RFC 5036. It’s not necessary that an IPV6 FEC should be resolved by an IPV6 only route next-hop. The hello adjacency can still be over an IPV4 link and IPV6 prefix can still be resolved by an IPV4 route next-hop. It’s not necessary that source of hellos be IPv6 or transport address of TCP session be ipv6.****
>
> ** **
>
> **3.                     **This clause has unnecessary scalability implications. We do run very large number of LDP adjacencies/sessions (e.g 10K) in mobility backhauls or similar deployments. This clause requires to run 20K hello adjacencies which has scalability implications. On theory there may not much difference between 10K and 20K but in real implementations there is. If we allow separation of sessions for fate separation of IPV4 and IPV6 then it would become 40K adjacencies.****
>
> ** **
>
> We can limit to only one hello adjacency per interface yet address the dual stack issue. A graceful solution is to come up with a notion of LDP adjacency specific capabilities (similar to LDP capabilities that applies to entire sessions) that would benefit multiple purposes. For example, we have multiple ECMP Links between neighboring LSRs A and B as shows below.****
>
> ** **
>
>                                    +----------------L1------------------+****
>
>                                    |                                             |****
>
>                                   A ----------------L2----------------- B****
>
>                                    |                                             |****
>
>                                    +----------------L3------------------+****
>
> ** **
>
> The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using either IPV4 OR ipv6 addresses but not both.****
>
> ** **
>
> Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3 are IPv6 capable. ****
>
> ** **
>
> Then hellos exchanged over link would advertise capabilities as below:****
>
> ** **
>
> L1 would carry capabilities – Ipv4 + Mcast****
>
>       L2 would carry capabilities – ipv4 + ipv6 + Mcast****
>
>       L3 would carry capabilities – ipv4 + ipv6 ****
>
> ** **
>
>  ****
>
> From an implementer/system designer’s point of view I would think single hello adjacency with per adjacency capabilities would be right approach. ****
>
> ** **
>
> Thanks,****
>
> Pranjal ****
>
> ** **
>  ------------------------------
>
> *From:* **Vishwas Manral** [mailto:[email-masked]]
> *Sent:* Wednesday, February 29, 2012 5:11 PM
> *To:* **Dutta, Pranjal K** (Pranjal)
> *Cc:* Lizhong Jin; **Aissaoui, Mustapha** (Mustapha); [email-masked]**
> *Subject:* Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06****
>
> ** **
>
> because the new LSR ID would then need to be exchanged. We could treat it
> Vishwas****
> On Wed, Feb 29, 2012 at 5:03 PM, **Dutta, Pranjal K** (Pranjal) <
> [email-masked]> wrote:****
>
> mapping of 4 byte LSR-ID to an IPV6 remote address.****
>
> with a local ipv4 interface address in the system.****
>
>  ****
>
> Thanks,****
>
> Pranjal****
>
>  ****
>  ------------------------------
>
> *From:* Lizhong Jin [mailto:[email-masked]]
> *Sent:* Wednesday, February 29, 2012 4:57 PM
> *To:* **Aissaoui, Mustapha** (Mustapha)
> *Cc:* [email-masked]; **Dutta, Pranjal K** (Pranjal);
> [email-masked]****
>
>
> *Subject:* RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06****
>
>  ****
>
> ** **
>
> Hi Mustapha,
> "**Aissaoui, Mustapha** (Mustapha)" <[email-masked]>
> > **Aissaoui, Mustapha** (Mustapha)
> > To: Lizhong Jin; **Dutta, Pranjal K** (Pranjal); [email-masked]
> > Cc: [email-masked]
> > To: **Dutta, Pranjal K** (Pranjal); [email-masked]; Aissaoui,
> > Mustapha (Mustapha)
> > Cc: [email-masked]
> > > From: "**Dutta, Pranjal K** (Pranjal)" <
> [email-masked]>
> > > To: **Vishwas Manral** <[email-masked]>
> > > Cc: "**Aissaoui, Mustapha** \(Mustapha\)"
> system.****
> ** **

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sat, 3 Mar 2012 01:46:26 +0530

Hi Viswas,
                          However the key issue is running of two separate hello adjacencies for IPV4 and IPV6 over single interface between same peering LSRs.
Thanks,
Pranjal

Sent: Friday, March 02, 2012 11:50 AM

Hi Pranjal/ Mustapha,

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

Thanks,
Vishwas
On Fri, Mar 2, 2012 at 11:37 AM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
Yes, this approach would lead to all "kludgy" implementations. Due to race conditions between UDP based LDP hellos and TCP connections (since they are independent channels) it may lead to states of continually flapping sessions.

Thanks,
Pranjal

Cc: Lizhong Jin; [email-masked]<mailto:[email-masked]>

Mustapha.

Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>

Section 6.2

                                   |                                             |

                                   |                                             |

Thanks,

Pranjal

________________________________
From: Vishwas Manral [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 29, 2012 5:11 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Thanks,
Vishwas

Thanks,
Pranjal

Hi Mustapha,

Thanks
Lizhong

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 6 Mar 2012 00:08:58 +0530

Yes this is what I have been mentioning for long. There are various FEC type capabilities already defined in several other drafts in this WG.
Just port them to advertise with Hellos to fit wherever applicable - and term it as "LDP Hello Adjacency Capabilities". Then you have the ability to
selectively pickup interfaces for programming the egress for specific fec types based on capabilities.

Thanks,
Pranjal
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Sunday, March 04, 2012 10:39 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

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

Regards
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 2012/03/03 02:22:22:

> maintained on dual-stack - one for IPV4 and another for IPV6. We
> don't see any benefit or technical reason of running two separate
> adjacencies.
>
> 5.5 in  RFC 5036. It's not necessary that an IPV6 FEC should be
> an IPV4 route next-hop. It's not necessary that source of hellos be

---

From: Mark Tinka <[email-masked]>
Date: Wed, 7 Mar 2012 18:14:03 +0800

On Saturday, March 03, 2012 03:26:00 AM Aissaoui, Mustapha 
(Mustapha) wrote:

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

Mustapha, I was reviewing the I-D and also found this piece 
of spec.

I have to admit that I'm not necessariy a fan of making IPv6 
be the preferred transport mechanism in case the interface 
is dual-stacked.

As mentioned, if IPv4 bootstraps the adjacency and then the 
addition of an IPv6 address changes this while in flight, 
this is counter-intuitive from an operator perspective.

I would rather we revise this text so that IPv4 and IPv6 
adjacencies are started based on the presence of either AF 
on an interface. Of course, if vendors want to provide 
operators with knobs to change this behaviour so that it 
conforms to the current spec. in the I-D, they may do so. 
But IMHO, this will be giving operators more rope to hang 
themselves with than they really need.

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Wed, 7 Mar 2012 18:16:53 +0800

On Saturday, March 03, 2012 03:49:57 AM Vishwas Manral 

> This has been discussed a few times over already.

Sorry Vishwas, it would appear that I missed those earlier 
discussions :-).

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

So are you suggesting that if we don't prefer IPv6 over IPv4 
for adjacency creation (and we have separate adjacencies for 
IPv4 and IPv6), we can't simply assume that the IPv4 
adjacency is maintaining the IPv4 session, or that the IPv6 
adjacency is maintaining the IPv6 session?

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Wed, 7 Mar 2012 18:22:52 +0800

On Tuesday, March 06, 2012 02:31:23 AM Dutta, Pranjal K 
(Pranjal) wrote:

>  We can satisfy both fate-shared and fate-separation
> requirements using single hello adjacency (with per
> adjacency capabilities) associated with a remote lsr-id.

I think given that turning on LDP in a network will 
immediately cause IPv4 (or IPv6) traffic to be forwarded 
using LSP's that have been created as a result, I'm not sure 
operators would be happy to find themselves in situations 
where an adjacency is enabling both LDPv4 and LDPv6, and yet 
they probably didn't want to forward IPv6 Internet traffic 
using MPLS at that particular point in time.

If vendors will provide options to toggle LDPv6 in new code 
that implements it, we might as well separate the 
adjacencies for IPv4 and IPv6 in the process. The example I 
gave above is one case; but in general terms, it would be 
good if issues affecting the adjacency don't take down both 
versions of LDP due to fate-sharing of the session, and yet 
perhaps only one of the AF's needed to be affected.

At its most basic level, LDP will lead to forwarding of 
global table IP packets via MPLS. This can be a big deal, 
even before other fancy capabilities like mLDP, pw, e.t.c., 
are considered.

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Wed, 7 Mar 2012 18:26:55 +0800

On Wednesday, March 07, 2012 02:27:39 AM Dutta, Pranjal K 
(Pranjal) wrote:

>          If we run multiple ldp sessions between peering
> systems for fate separation of ipv4 and ipv6 then there
> can be two separate hello adjacencies over a single
> interface (each one associated with separate sessions)
> but in that case the LSR-IDS used would be different (we
> need to work for an extension of RFC 5036).

I would be in favour of the above.

Vendors could go ahead and implement support for a single 
adjacency that carries both sessions, but experience 
suggests operators will choose the latter instead, 
instinctively.

LDP has also prided itself on being simple, so I'm not sure 
whether providing all these options to operators via CLI 
will be in keeping with that mantra (especially in relation 
to the defaults various vendors may choose to run in multi-
vendor-operated networks).

Mark.

---

From: "t.petch" <[email-masked]>
Date: Wed, 7 Mar 2012 16:39:50 +0100

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Shane Amante" <[email-masked]>; "Kamran Raza" <[email-masked]>
Sent: Thursday, March 01, 2012 6:16 PM
----- Original Message -----
From: "Shane Amante" <[email-masked]>
To: "Kamran Raza" [email-masked]
Sent: Thursday, March 01, 2012 4:45 PM

Kamran,

<tp>

<tp2>
With that wonderful timing of happenstance, this just got posted to the
Operational Security WG list

-------------------------------------------------------------------
Date: Tue, 6 Mar 2012 10:51:11 -0300
From: Fernando Gont [email-masked]
Subject: Re: [OPSEC] New Version Notification for
 draft-yourtchenko-opsec-humansafe-ipv6-00.txt

On 03/06/2012 10:06 AM, Andrew Yourtchenko wrote:
>>> Example: 2001:db8:d923:297a:2068:d95d:cff5:308a. Make an experiment and
>>> measure how much it takes to get this address over to someone over the
>>> phone, without errors. That's the type of problem I had in mind.
>>
>> I know of quite a few folks that have already established the rule that
>> "you don't tell IPv6 addresses over the phone"
>
> Indeed, precisely because of this problem, I suspect.

Exactly.
-----------------------------------------------------------------------

I see the world as divided into those who know IPv6 addresses are a nightmare
and those who have yet to discover that IPv6 addresses are a nightmare:-)

Tom Petch

---

From: Mark Tinka <[email-masked]>
Date: Thu, 8 Mar 2012 11:15:49 +0800

On Wednesday, March 07, 2012 11:39:50 PM t.petch wrote:

> I see the world as divided into those who know IPv6
> addresses are a nightmare and those who have yet to
> discover that IPv6 addresses are a nightmare:-)

But what else are you going to do?

Unless vendors decide to start implementing DNS-based 
Router-ID and LSR-ID definitions in CLI (just kidding, guys, 
please don't do that) :-).

Mark.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 8 Mar 2012 09:45:55 -0600

Mark,
It is bit awkward that some of the email postings are being delayed for some reason and as such the flow of exchange may not seem very natural.

I think we all agree that having two adjacencies sharing the same LDP session is not a good thing. We should indeed allow operators to have an IPv6 adjacency bootstrap and IPv6 session separately from the IPv4 adjacency bootstrapping an IPv4 session. This is consistent with RFC 5036. 

The knob that we were referring to is different. What we are saying is that once say an IPv6 adjacency bootstrapped and IPv6 LDP session, we should allow flexibility of which address family FECs can be advertized over that session. In other words, we can certainly exchange IPv6 unicast FECs, but also IPv4 unicast FECs, mLDP P2MP FECs, PW FECs, etc.  This is all under the control of the operator who can use the LDP node capability and/or the FEC filters to decide which FEC families are allowed over that session. For instance, you can decide that only IPv6 unicast FECs should be exchanged over this IPv6 LDP session and this is fine. 

Think about it like in BGP which allows advertizing IPv4 NLRI over an IPv6 TCP connection and vice-versa. You use it they way you think is appropriate to you but it has the flexilbility to advertise routes of different address families over the same IPv6 (or IPv4) TCP connection.

Regards,
Mustapha.

-----Original Message-----
From: Mark Tinka [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2012 5:14 AM
To: [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); Dutta, Pranjal K (Pranjal); Vishwas Manral; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

(Mustapha) wrote:

> draft suggests in Section 6.1 - Transport connection establishment, 
> that a TCP connection with IPv6 should be preferred to one with
> IPv4 if both IPv4 and IPv6 adjacencies exist. This means that if the 
> IPv4 adjacency came up first and boot straps the IPv4 TCP connection, 
> as soon as the IPv6 hello is established, we tear down the IPv4 TCP 
> connection and signal the IPv6 one. This of course is not acceptable.
> In RFC 5036 compliant implementations, when a new adjacency comes up 
> to the same LSR-ID, we just associate it with the existing TCP 
> connection which was bootstrapped by the first Hello adjacency.

Mustapha, I was reviewing the I-D and also found this piece of spec.

I have to admit that I'm not necessariy a fan of making IPv6 be the preferred transport mechanism in case the interface is dual-stacked.

As mentioned, if IPv4 bootstraps the adjacency and then the addition of an IPv6 address changes this while in flight, this is counter-intuitive from an operator perspective.

I would rather we revise this text so that IPv4 and IPv6 adjacencies are started based on the presence of either AF on an interface. Of course, if vendors want to provide operators with knobs to change this behaviour so that it conforms to the current spec. in the I-D, they may do so. 
But IMHO, this will be giving operators more rope to hang themselves with than they really need.

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Fri, 9 Mar 2012 00:02:40 +0800

On Thursday, March 08, 2012 11:45:55 PM Aissaoui, Mustapha 
(Mustapha) wrote:

> It is bit awkward that some of the email postings are
> being delayed for some reason and as such the flow of
> exchange may not seem very natural.

Indeed :-).

> I think we all agree that having two adjacencies sharing
> the same LDP session is not a good thing. We should
> indeed allow operators to have an IPv6 adjacency
> bootstrap and IPv6 session separately from the IPv4
> adjacency bootstrapping an IPv4 session. This is
> consistent with RFC 5036.

Agreed.

> The knob that we were referring to is different. What we
> are saying is that once say an IPv6 adjacency
> bootstrapped and IPv6 LDP session, we should allow
> flexibility of which address family FECs can be
> advertized over that session. In other words, we can
> certainly exchange IPv6 unicast FECs, but also IPv4
> unicast FECs, mLDP P2MP FECs, PW FECs, etc.  This is all
> under the control of the operator who can use the LDP
> node capability and/or the FEC filters to decide which
> FEC families are allowed over that session. For
> instance, you can decide that only IPv6 unicast FECs
> should be exchanged over this IPv6 LDP session and this
> is fine.

Well, the operator assumption, in its default state, would 
be that if any capabilities are available across a session, 
they correspond to the AF running the session.

So if my LDPv6 is signaling support for Unicast FEC's, mLDP 
p2mp or mp2mp FEC's, pw FEC's and the rest, I'd naturally 
assume that these are of the IPv6 AF variety.

I suppose we can provide for mis-matched session-capability 
flexibility here, which vendors can implement as a knob; I 
wouldn't be entirely opposed to this idea, but would prefer 
this not to be the default behaviour if at all possible, 
across all implementations.

> Think about it like in BGP which allows advertizing IPv4
> NLRI over an IPv6 TCP connection and vice-versa. You use
> it they way you think is appropriate to you but it has
> the flexilbility to advertise routes of different
> address families over the same IPv6 (or IPv4) TCP
> connection.

Or like running 6PE :-).

Like I mentioned in a previous post about choosing dual-
stack over 6PE, we'd rather lose sleep building a dedicated 
BGP policy per AF than share the same one for both IPv4 and 
IPv6. Strange things have been known to happen when you 
share policies, so much so that it ends up never being worth 
the trouble for some installations. But I digress... :-).

Cheers,

Mark.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 09:03:33 -0500

Hi Shane,

Please see inline,

> So, please tell me how I'm supposed to ping/traceroute to this 32-bit
"Router
> ID" in this new IPv6-only world, just like I do today in IPv4 today,
to verify
> reachability?  

Good question. We should be pinging/tracerouting peer's Transport
address or TCP connection address, not Router ID. This is similar to
what we typically do with OSPF, for ex.

I am pasting the sample show command output (from Cisco and Juniper
routers) to better illustrate this (notice ^^^^^^). While the output
shows IPv4 transport address since the session is LDPoIPv4, it would be
an IPv6 addresses if the session was LDPoIPv6.  

//
JUNIPER ROUTER
=============
user@host> show ldp neighbor extensive
...
   Transport address: 10.255.245.5, Configuration sequence: 6
   ^^^^^^^^^^^^^^^^^^^^^^^^
..
//

CISCO ROUTER
============
RP/0/RP0/CPU0:router# show mpls ldp neighbor  
  
  Peer LDP Identifier: 10.44.44.44:0
    TCP connection: 10.44.44.44:65535 - 10.33.33.33:646
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Graceful Restart: No
    State: Oper; Msgs sent/rcvd: 49/46
    Up time: 00:33:33
    LDP Discovery Sources: 
      POS 0/1/0/0
...
//

> Usually, this is one of the first steps in troubleshooting a
> problem.  I'm curious if we've gotten lazy by assuming dual-stack v4 +
v6 will
> "always be there", so I can just use v4 to ping/traceroute to a 32-bit
Router ID

Not at all. In fact, we continue to consider IPv6-only (which will exist
for long long time) and add the relevant/missing pieces to accommodate
dual-stack (which will disappear sooner or later) while thinking about
IPv6 LDP. 

Again, the router ID is a 32-bit quantity, whether it is used for IPv6
BGP, or IPv6 OSPF or IPv6 LDP or all of them.

> FWIW, I was suggesting another imperfect "hack" wrt (b). Specifically,
a
> protocol could use/exchange/etc. a 32-bit ROUTER_ID on-the-wire;
> however, "out-of-band" I assign a IPv4-mapped IPv6 address to a
Loopback
> interface on a router and inject it into my "IPv6-only" IGP in order
to
> preserve my ability to see it in the topology (in the routing table),
and
> simultaneously am able to ping/traceroute to it to ensure that the
Loopback
> interface is "alive".  But, this is a kludge, because now I have to
keep the
> ROUTER_ID in sync with the configuration of IPv4-mapped IPv6 address
on a
> Loopback interface ...

Aaah, I follow it now. Thanks for clarifying it. This could be a
reasonable option for a deployment, but certainly not pretty.    

Interestingly, there are few deployments that actually use the last
(non-zero) 32-bits of the assigned "IPv6 prefix" as the Router Id for
IPv6 BGP and IPv6 OSPF. This doesn't require any IPv4-mapped-IPv6
address usage and works reasonably well for consistency. This depends on
the addressing schema though.

Cheers,
Rajiv

> Sent: Friday, March 02, 2012 2:02 AM
> To: Rajiv Asati (rajiva)
> Cc: t.petch; Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
> So, please tell me how I'm supposed to ping/traceroute to this 32-bit
"Router
> ID" in this new IPv6-only world, just like I do today in IPv4 today,
to verify
> reachability?  Usually, this is one of the first steps in
troubleshooting a
> problem.  I'm curious if we've gotten lazy by assuming dual-stack v4 +
v6 will
> "always be there", so I can just use v4 to ping/traceroute to a 32-bit
Router ID
> ... but, what happens when v4 is no longer there any more?
> 
> 
> FWIW, I was suggesting another imperfect "hack" wrt (b). Specifically,
a
> protocol could use/exchange/etc. a 32-bit ROUTER_ID on-the-wire;
> however, "out-of-band" I assign a IPv4-mapped IPv6 address to a
Loopback
> interface on a router and inject it into my "IPv6-only" IGP in order
to
> preserve my ability to see it in the topology (in the routing table),
and
> simultaneously am able to ping/traceroute to it to ensure that the
Loopback
> interface is "alive".  But, this is a kludge, because now I have to
keep the
> ROUTER_ID in sync with the configuration of IPv4-mapped IPv6 address
on a
> Loopback interface ...

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 09:24:14 -0500

Shane, Pranjal,

Let's make sure that we don't have any disconnect here at least on the
technicalities here (ignoring the draft discussion for a minute)

Shane's Q is whether either v4 or v6 hello could help to establish v4
and/or v6 LDP session. 
While Pranjal's assertion is correct on its own, it doesn't quite answer
the subtlety in Shane's Q.

Shane's Q:
> With respect to LDP Hellos, you're suggesting that operators run
either IPv4-
> only Hello's or IPv6-only Hello's, (never both at the same time), but
through
> either one can discover the "(IPv4|IPv6) transport capabilities" of a
LDP peer
> and, based on that, establish an IPv4 and/or IPv6 LDP session.
Correct?

Not really. Using v4 hello MUST not lead to using v6 transport and v6
LDP session. That would be a fundamentally wrong approach.

As Pranjal said, v4 hello usage must lead to v4 session establishment,
whereas v6 hello usage must lead to v6 session establishment.

Cheers,
Rajiv

Of
> Sent: Tuesday, March 06, 2012 1:28 PM
> To: Shane Amante
>           Yes, that's correct. We can run either ipv4 hellos or ipv6
hellos and
> operator can choose whichever is best,  based upon the operational
needs.
> Since the src ip addresses used by hello packets are not coupled with
FEC
> types so single hello can advertise various FEC capabilities.
> 
>          If we run multiple ldp sessions between peering systems for
fate
> separation of ipv4 and ipv6 then there can be two separate hello
adjacencies
> over a single interface (each one associated with separate sessions)
but in
> that case the LSR-IDS used would be different (we need to work for an
> extension of RFC 5036).
> 
> Thanks,
> Pranjal
> 
> >          Yes, two separate LDP sessions are required for fate
separation of ipv4
> and ipv6 fecs.
> With respect to LDP Hellos, you're suggesting that operators run
either IPv4-
> only Hello's or IPv6-only Hello's, (never both at the same time), but
through
> either one can discover the "(IPv4|IPv6) transport capabilities" of a
LDP peer
> and, based on that, establish an IPv4 and/or IPv6 LDP session.
Correct?
> > I completely agree with all of your comments below. I too would
(strongly)
> prefer the option to allow operators to choose (via CLI) whether to:
> > a) use separate transport to ensure there is no fate-sharing of IPv4
+
> > IPv6; or,
> > b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or,
other
> AF's) on a single session, for scale reasons.
> >
> > -shane
> >
> >

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 09:31:20 -0500

Mustapha,

That's not the correct interpretation of section 6.1. 

 If the session already exists (e.g. TCP socket is in place) for a peer,
then any request for a new session using a different transport or  not
would be ignored.
Please allow me to paste the relevant excerpt from the ldp-ipv6-06 :

//
     6. An LSR SHOULD NOT create (or honor the request for creating) a
        TCP connection for a new LDP session with a remote LSR, if they
       already have an LDP session (for the same LDP Identifier)
        established over whatever IP version transport.

//

Please let us know if this can be phrased better.

Cheers,
Rajiv

Of
> Sent: Friday, March 02, 2012 2:26 PM
> To: Dutta, Pranjal K (Pranjal); VishwasManral
> Cc: [email-masked]; Lizhong Jin
draft
> suggests in Section 6.1 - Transport connection establishment, that a
TCP
> connection with IPv6 should be preferred to one with IPv4 if both IPv4
and
> IPv6 adjacencies exist. This means that if the IPv4 adjacency came up
first
> and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is
> established, we tear down the IPv4 TCP connection and signal the IPv6
one.
> This of course is not acceptable. In RFC 5036 compliant
implementations,
> when a new adjacency comes up to the same LSR-ID, we just associate it
> with the existing TCP connection which was bootstrapped by the first
Hello
> adjacency.
clause in the
> draft.
> maintained on dual-stack - one for IPV4 and another for IPV6. We don't
see
> any benefit or technical reason of running two separate adjacencies.
> 
way. Both IPV4
> and IPV6 fecs are still exchanged over same LDP sessions.
> 
IPV6 LSPs
> must provision IPv6 interfaces.  It is not mandatory that the
transport
> network itself be IPV6 in order to carry IPV6 traffic over its
tunnels. This is a
> very narrow interpretation of section 2.5.5 in  RFC 5036. It's not
necessary
> that an IPV6 FEC should be resolved by an IPV6 only route next-hop.
The
> hello adjacency can still be over an IPV4 link and IPV6 prefix can
still be
> resolved by an IPV4 route next-hop. It's not necessary that source of
hellos
> be IPv6 or transport address of TCP session be ipv6.
> 
run very large
> number of LDP adjacencies/sessions (e.g 10K) in mobility backhauls or
similar
> deployments. This clause requires to run 20K hello adjacencies which
has
> scalability implications. On theory there may not much difference
between
> 10K and 20K but in real implementations there is. If we allow
separation of
> sessions for fate separation of IPV4 and IPV6 then it would become 40K
> adjacencies.
> 
> We can limit to only one hello adjacency per interface yet address the
dual
> stack issue. A graceful solution is to come up with a notion of LDP
adjacency
> specific capabilities (similar to LDP capabilities that applies to
entire sessions)
> that would benefit multiple purposes. For example, we have multiple
ECMP
> Links between neighboring LSRs A and B as shows below.
> 
>
>                                    |
|
>                                    |
|
> 
> The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using
either
> IPV4 OR ipv6 addresses but not both.
> 
single
> hello adjacency with per adjacency capabilities would be right
approach.
well
it
LSR-ID
pointed out
scalability impacts.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 09:33:23 -0500

Pranjal,

Certainly. That would be a sub-optimal protocol design,  let alone the
subsequent implementations.
Thankfully, that's not what is prescribed.

May I request you to review the verbiage a bit carefully?

Cheers,
Rajiv

Of
> Sent: Friday, March 02, 2012 2:37 PM
> To: Aissaoui, Mustapha (Mustapha); Vishwas Manral
> Yes, this approach would lead to all "kludgy" implementations. Due to
race
> conditions between UDP based LDP hellos and TCP connections (since
they
> are independent channels) it may lead to states of continually
flapping
> sessions.
draft
TCP
and
first
one.
implementations,
Hello
clause in the
see
> 1.                     First of all, doing so does not provide fate
separation any way.
> Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions.
> 
> 2.                     This clause mandates that a transit network
that is carrying IPV6
> LSPs must provision IPv6 interfaces.  It is not mandatory that the
transport
tunnels. This is a
necessary
The
still be
hellos
> 3.                     This clause has unnecessary scalability
implications. We do run
> very large number of LDP adjacencies/sessions (e.g 10K) in mobility
> backhauls or similar deployments. This clause requires to run 20K
hello
> adjacencies which has scalability implications. On theory there may
not much
> difference between 10K and 20K but in real implementations there is.
If we
> allow separation of sessions for fate separation of IPV4 and IPV6 then
it
> would become 40K adjacencies.
> 
dual
adjacency
entire sessions)
ECMP
|
|
either
single
approach.
well
it
LSR-ID
pointed out
scalability impacts.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 09:43:58 -0500

Mark,

> be the preferred transport mechanism in case the interface

We maintained the IPv6 as the preferred transport mechanism (during
collision) after we polled the WG during IETF 80.

Nonetheless, your preference is reasonable and that's why the draft has
the following in section 6.1:

//
   An implementation may provide an option to favor one AFI (IPv4, say)
   over another AFI (IPv6, say) for the TCP transport connection, so as
   to use the preferred IP version for the LDP session, and derive
//

> on an interface. 

Of course, unless LDP for IPv4 or IPv6 is enabled on an interface, an
LSR must not attempt to form LDP adjacency for that AFI. 
Which section do you find the draft saying the opposite?

Cheers,
Rajiv

Of
> Mark Tinka
> Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 09:46:33 -0500

Mark,

I think that Vishwas is referring to is this verbiage in section 6.1:

//

Cheers,
Rajiv

Of
> Mark Tinka
> Sent: Wednesday, March 07, 2012 5:17 AM
> To: [email-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 09:51:37 -0500

Mark,

> suggests operators will choose the latter instead,

Interestingly, what we find is the dominance of single-session BGP for
exchanging multiple AFI/SAFI information in deployments.
In fact, many operators have justified moving (from OSPF) to ISIS to
have a single process provide both v4 and v6.

AFAIK, the multi-session BGP capability, which has existed for 7-8yrs,
has seen minimal deployment. 

Cheers,
Rajiv

Of
> Mark Tinka
> Sent: Wednesday, March 07, 2012 5:27 AM

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 21:54:54 +0530

Rajeev,
        We are not discussing about text rephrasing here and have been raising technical issues. Could you please respond on my earlier mail
on technical reasons on why it is MUST to have hello adjacency over 
both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? 

Cheers,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Monday, March 12, 2012 7:33 AM
To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas Manral
Cc: [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Cheers,
Rajiv

Of
race
they
flapping
draft
TCP
and
first
one.
implementations,
Hello
clause in the
see
separation any way.
that is carrying IPV6
transport
tunnels. This is a
necessary
The
still be
hellos
implications. We do run
hello
not much
If we
it
dual
adjacency
entire sessions)
ECMP
|
|
either
single
approach.
well
it
LSR-ID
pointed out
scalability impacts.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 11:28:29 -0500

Pranjal,

> both IPV4 and IPV6 in order to be able to set-up IPV6 FECs?

When you say set-up IPv6 FECs, you mean IPv6 FEC advertisement?

Cheers,
Rajiv

> Sent: Monday, March 12, 2012 12:25 PM
> To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas
Manral
>         We are not discussing about text rephrasing here and have been
raising
> technical issues. Could you please respond on my earlier mail
Of
> Rajiv Asati (rajiva)
don't
> > We can limit to only one hello adjacency per interface yet address
the
> > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are
using
with
> lucent.com>
[email-masked]
LSR-ID.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 22:00:14 +0530

There are more subtleties involved when we talk on real implementation.

If order to have fate separation between IPV4 and IPV6, we need separation of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been different, so obviously it would lead to two separate LDP sessions.
Howevever whether both an implementation wants to send hellos for both 
adjacencies on a same interface (either ipv4 or ipv6) or different 
interfaces is implementation specific. We send hellos over an interface 
as intent of a LSR to include that interface for traffic and multiple 
LSRs can hellos with same source ip address. 

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Monday, March 12, 2012 7:24 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Shane, Pranjal,

either IPv4-
through
LDP peer
Correct?

Cheers,
Rajiv

Of
hellos and
needs.
FEC
fate
adjacencies
but in
separation of ipv4
either IPv4-
through
LDP peer
Correct?
(strongly)
+
other

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 22:08:23 +0530

Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6 FECs by upstream towards downstream.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Monday, March 12, 2012 9:28 AM
To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas Manral
Cc: [email-masked]; Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Cheers,
Rajiv

Manral
raising
Of
don't
the
using
with
[email-masked]
LSR-ID.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 11:51:03 -0500

Pranjal,

Could you please point to the relevant section in the ldp-ipv6 draft?

Cheers,
Rajiv

> Sent: Monday, March 12, 2012 12:38 PM
Manral
> Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6
FECs by
> upstream towards downstream.
> 
> > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha);
Vishwas
> > > when a new adjacency comes up to the same LSR-ID, we just
associate
> > >    IPv4 and IPv6 LDP, then the LSR must periodically send both
IPv4
> > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN).
> L2
> > > and L3 are IPv6 capable.
> > >
I
sessions
> > > > > sharing would continue over the single ldp/tcp session for
IPV4
> > and IPV6.
> > > > > only decide whether such a link is to be programmed for IPV4
or
> > IPV6

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 22:25:32 +0530

Rajeev,
        Refer to following:

"Section 6.1

 3. An LSR MUST send separate Hellos (each containing either IPv4
   or IPv6 transport address optional object) for each IP address-
   family, if LDP was enabled for both IP address-families."

Cheers,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Monday, March 12, 2012 9:51 AM
To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas Manral
Cc: [email-masked]; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Cheers,
Rajiv

Manral
FECs by
Vishwas
associate
IPv4
I
sessions
IPV4
or

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 12:05:43 -0500

Pranjal,

Thanks. Perhaps, you meant to point to another section, since that
doesn't say anything about what you asked:

> FECs by upstream towards downstream.

Cheers,
Rajiv

> Sent: Monday, March 12, 2012 12:56 PM
Manral
Of
Vishwas
> > > > Yes, this approach would lead to all "kludgy" implementations.
Due
> > > > are independent channels) it may lead to states of continually
implementation.
> > The
> > > draft
> > > > suggests in Section 6.1 - Transport connection establishment,
that
> a
> > > TCP
> > > > connection with IPv6 should be preferred to one with IPv4 if
both
> > IPv4
> > > and
> > > > IPv6 adjacencies exist. This means that if the IPv4 adjacency
came
> > up
> > > first
> > > > and boot straps the IPv4 TCP connection, as soon as the IPv6
hello
> > is
> > > >      forwarding on a dual-stacked interface, as well as
successful
> > > > resolved by an IPV4 route next-hop. It's not necessary that
source
> > > > allow separation of sessions for fate separation of IPV4 and
IPV6
> > then
> > > > The second could lead to changes required in both OSPF and
IS-IS,
> > > > > actually populate the field with a /32 address in IPv4 and
thus
> If
> > > > > capability, not per interface capability. But for LDP to
choose
> > > > > should also check if the output interface is LDP enabled or
not.
> > > > > for IPv4 and IPv6 as an option. Regarding the format
definition
> > > > > intended solely for the use of the individual or entity to
whom

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 12:13:38 -0500

Pranjal,

> interfaces is implementation specific.

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

>  We send hellos over an interface

Thanks for sharing the implementation details. 

I followed the first part (and agreed), but I didn't follow the 2nd part
(i.e. multiple LSRs can hellos with same source ip address), but it
sounded incorrect.

> If order to have fate separation between IPV4 and IPV6, we need
separation
> of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been
different,
> so obviously it would lead to two separate LDP sessions.

I will shy away from the above circular logic. :-)
Nonetheless, different LSR-IDs is one way to get to multi-session LDP.

Cheers,
Rajiv

> Sent: Monday, March 12, 2012 12:30 PM
> To: Rajiv Asati (rajiva); Shane Amante
> If order to have fate separation between IPV4 and IPV6, we need
separation
> of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been
different,
> so obviously it would lead to two separate LDP sessions.
Of
> > >> Pranjal, I appreciate that from a vendor perspective,
implementing
> > >> However, for some operators who may be using BGP or RSVP to
signal

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 22:45:03 +0530

Rajiv,
        What do you mean????? There is a complete disconnect. I have asked an explicit question - "What makes it mandatory (MUST) to have two separate hello adjacencies when there is no real fate separation?" I haven't still got the answer from you. Is this a mandatory requirement for IPV6 FEC next-hop resolution  or FEC advertisement? Please justify with technical reasons (only).

Cheers,
Pranjal

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Monday, March 12, 2012 10:06 AM
To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas Manral
Cc: [email-masked]; Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Cheers,
Rajiv

Manral
Of
Vishwas
Due
implementation.
that
both
came
hello
successful
source
IPV6
IS-IS,
thus
choose
not.
definition
whom

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 22:46:46 +0530

"It can't be, because it will break interoperability. This calls for
normative behavior."

Reference Please?

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 10:14 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

separation
different,

Cheers,
Rajiv

separation
different,
Of
implementing
signal

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 22:50:55 +0530

Rajiv,

"I will shy away from the above circular logic. :-) Nonetheless, different LSR-IDs is one way to get to multi-session LDP."

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

Cheers,
Pranjal

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Monday, March 12, 2012 10:14 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

normative behavior.

sounded incorrect.

separation

different,

Cheers,

Rajiv

> There are more subtleties involved when we talk on real

implementation.

separation

different,

> interfaces is implementation specific. We send hellos over an

interface

Of

> While Pranjal's assertion is correct on its own, it doesn't quite

answer

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

but

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

a

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

with

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

an

> > Cc: [email-masked]; Aissaoui, Mustapha (Mustapha);

> > [email-masked]; Lizhong Jin

> > > Separation of ipv4 and ipv6 hello adjacencies are not required to

> > > satisfy

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

but

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

a

> > > From: [email-masked] [mailto:[email-masked]] On

Behalf

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

IPv4

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

(or,

> > >>>> From an implementer/system designer's point of view I would

think

implementing

signal

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

> LDP.

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

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

> deploy

> > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's

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

> like

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

> wild.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 12:23:36 -0500

Pranjal,

Please consider this scenario - 
-  LSR A's implementation expects both v4 and v6 hellos from LSR B, 
 - LSR B's implementation sends only v4 hello to LSR B

That's why we shouldn't make this implementation specific.

Cheers,
Rajiv

> Sent: Monday, March 12, 2012 1:17 PM
Behalf
> > > >> If there are operators who aren't going to be looking at
scaling

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 22:55:12 +0530

Rajiv,
       May I request you to answer on the following we raised over the issue on dual-stack hello adjacencies made mandatory for ipv6 draft? We still haven't heard justifications from any of the authors...

Thanks,
Pranjal

-----Original Message-----
From: Dutta, Pranjal K (Pranjal) 
Sent: Monday, March 05, 2012 10:31 AM
To: [email-masked]'; [email-masked]
Cc: Vishwas Manral; Aissaoui, Mustapha (Mustapha); Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Mark,

-----Original Message-----
From: Mark Tinka [mailto:[email-masked]] 
Sent: Friday, March 02, 2012 9:10 PM
To: [email-masked]
Cc: Dutta, Pranjal K (Pranjal); Vishwas Manral; Aissaoui, Mustapha (Mustapha); Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

</Pranjal>

<\Pranjal> 

<Pranjal>

</Pranjal>

Mark.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Mar 2012 12:26:22 -0500

Pranjal,

I am sorry, but such remarks will not lead to any healthy discussion. 

Cheers,
Rajiv

> Sent: Monday, March 12, 2012 1:21 PM
> "I will shy away from the above circular logic. :-) Nonetheless,
different LSR-
> IDs is one way to get to multi-session LDP."
> 
> 
> 
> I don't see any circular logic. You seemed to be quite confused
between LDP
> hello adjacencies, its intent and LDP sessions.
> 
> 
> 
> Cheers,
> 
> Pranjal
> 
> 
> 
Behalf
scaling

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 22:58:02 +0530

Rajiv,
       I voted for win-win. Implementations can provide knob to toggle.
You can't force an operator that has ipv4 only links connecting LDP 
Network to provision ipv6 links in order to transport/set-up IPV6 FECs.
It won't break inter-operability.

Cheers,
Pranjal

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 10:24 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Cheers,
Rajiv

Behalf
scaling

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Mon, 12 Mar 2012 23:00:43 +0530

Rajeev,
        Who started this? I am raising technical issues but I am not getting any answers with technical justifications. We need to justify on technical 
front to carry forward a healthy discussion.

Cheers,
Pranjal

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 10:26 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; Lizhong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Cheers,
Rajiv

different LSR-
between LDP
Behalf
scaling