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

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 1 Mar 2012 17:25:05 -0600

Rajiv,
You have heard the requirements from operators on this mailing list asking for separate LDP sessions for IPv4 and IPv6. 

The draft in its current form does not meet this requirement and yet it adds constraints which makes it incompatible with RFC5036. It also doubles the number of Hello adjacencies for no gain.

What is the point of carrying forward this draft as is?

Mustapha.
Sent from my Blackberry!

----- Original Message -----
From: Rajiv Asati (rajiva) <[email-masked]>
To: Lizhong Jin <[email-masked]>; Vishwas Manral <[email-masked]>
Cc: Aissaoui, Mustapha (Mustapha); [email-masked] <[email-masked]>
Sent: Thu Mar 01 12:07:23 2012
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

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-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Lizhong Jin
> Sent: Thursday, March 01, 2012 3:46 AM
> To: Vishwas Manral
> Cc: Aissaoui, Mustapha (Mustapha); [email-masked]
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> 
> 
> 
> > Hi Lizhong/ Pranjal/ Mustapha,
> >
> > So the two main comments that have come after last call are:
> >
> > 1. Allow for separation of sessions along with the adjacency.
> > 2. Allow for an IPv6 based LSR-ID.
> >
> > The second could lead to changes required in both OSPF and IS-IS, as
> > well because the new LSR ID would then need to be exchanged. We
> > could treat it as an enhancement instead in my view. Do you agree?
> [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: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 1 Mar 2012 20:44:02 -0600

Hi Mustapha,

I was referring to LSR ID and router-id discussion in my response.
Router-id selection has nothing to do with separate LDP session per AFI.

Do you disagree to what I described wrt LSR ID being 4-octet? 

Cheers,
Rajiv

> From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-
> lucent.com]
> Sent: Thursday, March 01, 2012 6:25 PM
> To: Rajiv Asati (rajiva); [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> You have heard the requirements from operators on this mailing list asking
> for separate LDP sessions for IPv4 and IPv6.
> 
> The draft in its current form does not meet this requirement and yet it adds
> constraints which makes it incompatible with RFC5036. It also doubles the
> number of Hello adjacencies for no gain.
>

---

From: Mark Tinka <[email-masked]>
Date: Fri, 2 Mar 2012 11:09:02 +0800

On Friday, March 02, 2012 10:44:02 AM Rajiv Asati (rajiva) 
wrote:

> I was referring to LSR ID and router-id discussion in my
> response. Router-id selection has nothing to do with
> separate LDP session per AFI.
> 

Speaking operationally, we have experience (as all operators 
would) with 4-byte Router ID's being used for IPv6 
implementation of MP-BGP and OSPFv3 (we use IS-IS in our 
network, but having ran OSPFv3 in a previous life, that 
counts).

So technically, I would not be opposed to having a 4-byte 
LSR-ID which conforms to how BGP for IPv6, OSPFv3 and 
friends do it. However, I would like to be able to setup 
IPv4 LDP-based LSP's using a /32 IPv4 destination address, 
and do the same for IPv6 LDP-based LSP's using a /128 IPv6 
destination address.

I would not be overly inclined to wanting a 16-byte LSR-ID 
for LDPv6. The LSR-ID issue should be decoupled from the LSP 
session AF issue.

Of course, for some implementations that allow you to 
manually specify which interface the router should choose 
for the LDP LSR-ID (defining the Loopback interface tends to 
be typical), they would need to take dual-stack interfaces 
into account, and do the right thing in IPv6-aware LDP code, 
based on what is finally agreed on on this mailing list.

Mark.

---

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

Hi Mark,

Thanks for the response. Pls see inline,

> friends do it. 

Thanks for sharing that. 

Thankfully, this puts LDP inline with other protocols and eliminates any
guess-work. 
I am always told that such consistency (where applicable) is proven to
be operationally beneficial.

> However, I would like to be able to setup

Absolutely. This is an important point and well covered in section 3.

> for LDPv6. The LSR-ID issue should be decoupled from the LSP

I agree. IMO, it is indeed decoupled. 

> based on what is finally agreed on on this mailing list.

In the past, implementations provided the router-id CLI for any
interface IPv4 address to be chosen as router-id for various protocols
including LDP.
However, many implementations already evolved the CLI to not even give
an "interface" IP address for router-id, to accommodate IPv6.
Almost all deployed networks already accommodated that.

Now that LDP is being enhanced to use IPv6, implementations could evolve
LDP router-id as well to accommodate IPv6. This would make LDP router-id
to be consistent with other protocols delving with IPv6. And this can
certainly be operationally beneficial from IPv6 POV.

In fact, one of the implementations allow the router-id to be configured
just once and let all protocols just use it, if they wanted.  

Cheers,
Rajiv

> From: Mark Tinka [mailto:[email-masked]]
> Sent: Thursday, March 01, 2012 10:09 PM
> To: [email-masked]
> Cc: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha);
> [email-masked]; [email-masked]

---

From: Mark Tinka <[email-masked]>
Date: Fri, 2 Mar 2012 14:31:16 +0800

On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) 
wrote:

> In the past, implementations provided the router-id CLI
> for any interface IPv4 address to be chosen as router-id
> for various protocols including LDP.

> However, many implementations already evolved the CLI to
> not even give an "interface" IP address for router-id,
> to accommodate IPv6. Almost all deployed networks
> already accommodated that.

We do operate some implementations today that "still" allow 
you to specify the Router-ID for various protocols as an 
independent 32-bit integer (only), and also allow you to 
define the LSR-ID for LDP as an interface (only). This is 
current, shipping 2012 code.

So both scenarios you mention above are still much in play 
today. Whether operators are using them or not (I know we 
are) is another matter entirely.

> Now that LDP is being enhanced to use IPv6,
> implementations could evolve LDP router-id as well to
> accommodate IPv6. This would make LDP router-id to be
> consistent with other protocols delving with IPv6. And
> this can certainly be operationally beneficial from IPv6
> POV.

Agree.

> In fact, one of the implementations allow the router-id
> to be configured just once and let all protocols just
> use it, if they wanted.

Yes, we operate some implementations that use this method 
too. It's quite elegant, in that you configure once and 
forget. Other implementations that are more structured means 
operators could easily forget to specify the Router-ID for a 
particular protocol, for better or worse.

Cheers,

Mark.

---

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

Hi Mark,

Well said. 

I take that we are in agreement wrt 4-octet entity for LDP router-id in
the context of IPv6, as specified.  

Cheers,
Rajiv

> Sent: Friday, March 02, 2012 1:31 AM
> To: Rajiv Asati (rajiva)
> Cc: [email-masked]; Aissaoui, Mustapha (Mustapha);
[email-masked];

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 2 Mar 2012 07:42:03 +0100

Rajiv, I believe we need to provide both options to ensure both are possible. If we do not introduce the IPv6 LSR ID now I will be very hard to ad it in the future.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: vrijdag 2 maart 2012 7:39
To: [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Mark,

Well said. 

Cheers,
Rajiv

[email-masked];
> particular protocol, for better or worse.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Mark Tinka <[email-masked]>
Date: Fri, 2 Mar 2012 15:03:34 +0800

On Friday, March 02, 2012 02:38:42 PM Rajiv Asati (rajiva) 

> Hi Mark,

Hello Rajiv.

> I take that we are in agreement wrt 4-octet entity for
> LDP router-id in the context of IPv6, as specified.

Well, to be specific, I'm not opposed to having a 32-bit 
integer only, as it would be on par with what we're doing 
with BGP (as well as for other operators who are maintaining 
OSPFv3 implementations).

But if others feel we need to provide both options, 
particularly for LDP, I wouldn't argue with them either.

If both options are included in the spec., I'm not sure 
whether the IETF or the vendors should decide which one be 
the default.

Mark.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 2 Mar 2012 01:07:58 -0600

Hi Wim,

That's a reasonable point, but no such proposal has been made for other
protocols. In fact, IPv6 deployments have already accommodated 4-octet
router-id for routing protocols (which was also a departure from the
common practice in IPv4 realm). As Mark T and I discussed in the
previous email, the router-id consistency across protocols would be an
operational benefit. 

Focusing on the technicalities, Router ID is meant to ensure the
uniqueness of the router within the network while following the
protocol, so are we thinking that 4-octet is not good enough to ensure
the uniqueness? If so, then it would be worth having that discussion in
the Routing and Internet areas that have been focusing on IPv6 at large.

While I do agree to 128-bit future expandability as a benefit, the
benefit would be trivial (at the expense of message structure changes)
if we expanded it for the sake of it, but didn't address the root of the
problem. 

Do you think otherwise?

Cheers,
Rajiv 

> From: Henderickx, Wim (Wim) [mailto:[email-masked]]
> Sent: Friday, March 02, 2012 1:42 AM
> To: Rajiv Asati (rajiva); [email-masked]
> Rajiv, I believe we need to provide both options to ensure both are
possible.
> If we do not introduce the IPv6 LSR ID now I will be very hard to ad
it in the
> future.
Of
> Rajiv Asati (rajiva)

---

From: Mark Tinka <[email-masked]>
Date: Fri, 2 Mar 2012 15:10:55 +0800

On Friday, March 02, 2012 02:42:03 PM Henderickx, Wim (Wim) 
wrote:

> Rajiv, I believe we need to provide both options to
> ensure both are possible. If we do not introduce the
> IPv6 LSR ID now I will be very hard to ad it in the
> future.

I do see where Shane and Wim are coming from, as I did find 
it rather ambiguous that an IPv6-only router would need to 
specify a 32-bit integer as the Router-ID for some IPv6-
based routing protocols to work.

But we also need to be concerned about consistency across 
various protocols that operators are turning on. If 60% of 
all the key protocols are relying on the presence of a 32-
bit integer, even in an IPv6-only network, and then LDP (or 
some other protocol) has a different take on the matter, 
does that make things easier or harder for operators?

Personally, I'd have preferred Router-ID's for IPv4 and IPv6 
to be different per AF even for MP-BGP, OSPFv3 and others. 
But I realize this isn't the right thread for that, which is 
why I'm open to having both options in LDP.

The BGP and OSPF specs. are clear on this issue, but I 
certainly wouldn't mind them revisiting it in the future. If 
making LDP "dual-stack" in the Router-ID perspective is what 
may give the other working groups a kick-in-the-behind to 
consider the operational value (and challenges) of doing 
this in 2012 and beyond, I certainly won't stand in their 
way.

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Fri, 2 Mar 2012 15:20:36 +0800

On Friday, March 02, 2012 03:07:58 PM Rajiv Asati (rajiva) 
wrote:

> Focusing on the technicalities, Router ID is meant to
> ensure the uniqueness of the router within the network
> while following the protocol, so are we thinking that
> 4-octet is not good enough to ensure the uniqueness?

I think what Shane and Wim were alluding to is that even 
though the 32-bit integer was meant to provide uniqueness in 
the network, operators have actually made it routeable (by 
mapping the the Router-ID to the Loopback interface or some 
other interface on a router that is present in an IGP of 
choice).

While this may not have necessarily been the original intent 
of the spec., it is what has happened. So what Shane and 
them are trying to do is maintain that troubleshooting 
capability within an IPv6-only network.

However, ...

> If
> so, then it would be worth having that discussion in the
> Routing and Internet areas that have been focusing on
> IPv6 at large.

> While I do agree to 128-bit future expandability as a
> benefit, the benefit would be trivial (at the expense of
> message structure changes) if we expanded it for the
> sake of it, but didn't address the root of the problem.

... I do agree with Rajiv's assessment in the above two 
paragraphs.

Mark.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 2 Mar 2012 09:41:20 +0100

Rajiv,

I understand we didn't add a IPv6 router ID option in BGP/OSPF but we should look at the future to get to IPv6 only networks and as such it will be required. So we are now at a point where we should add this option in all protocols. Since LDP for Ipv6 is open we need to add it now. 

My 2 cents

Cheers,
Wim

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: vrijdag 2 maart 2012 8:08
To: Henderickx, Wim (Wim); [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Wim,

Do you think otherwise?

Cheers,
Rajiv 

possible.
it in the
Of

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 2 Mar 2012 08:42:54 -0600

Rajiv,
From a pure prootocol perspective, you are correct. 

This is however a practical matter. Many deployments today have the router-id default to a well known system loopback interface IPv4 address. This means that routing protocols, MPLS signaling protocols,and OAM protocols can operate directly using this address. Certainly with BGP, the operator can configure a neighbour address which is IPv6 and is different from the router-id but that router-id is already required for the operation of IPv4 BGP neighbours and other protocols and such this is manageable. As we go into all IPv6 deployments, we need to have means for deployments to have a similar default IPv6 system address. It is hardly justifiable at that point in time to configure two different addresses to get the prorotcols working by default. We may as well make this change now as part of allowing separate LDP sessions for IPv4 and IPv6 or we will create yet a third LDP version number in the next few years.

Regards,
Mustapha.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Thursday, March 01, 2012 9:44 PM
To: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Mustapha,

Cheers,
Rajiv

> You have heard the requirements from operators on this mailing list 
> asking for separate LDP sessions for IPv4 and IPv6.
> 
> The draft in its current form does not meet this requirement and yet 
> it adds constraints which makes it incompatible with RFC5036. It also 
> doubles the number of Hello adjacencies for no gain.
> 
> 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.
> RFC4271, to ensure the usage of 4-octet as the BGP ID in the context 
> of IPv6.
> 
> > > 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 
> > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as 
> > > I pointed out in my first email.
> > >
> > > Thanks
> > > 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
> > > > 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.
> > > >
> > > > To: Dutta, Pranjal K (Pranjal); [email-masked]; 
> > > > 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 
> > > > 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
> > > >
> > > >
> > > > >
> > > > 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
> > > > notify the originator of the message. Any views expressed in 
> > > > this message are those of the individual sender.

---

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

Rajiv,
       We shouldn't be ruling out the fact that there are some differences in applications of LDP compared to OSPF or BGP. If we have IPV6 only transport network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has to advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T-LDP has to auto-create targeted sessions. We can't force to set-up another ip4 network just for some applications. It won't be possible to map 4 byte ldp LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID is must for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility and better to add it now.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: Friday, March 02, 2012 12:41 AM
To: Rajiv Asati (rajiva); [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Rajiv,

My 2 cents

Cheers,
Wim

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: vrijdag 2 maart 2012 8:08
To: Henderickx, Wim (Wim); [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Wim,

Do you think otherwise?

Cheers,
Rajiv 

possible.
it in the
Of

---

From: Kishore Tiruveedhula <[email-masked]>
Date: Fri, 2 Mar 2012 16:08:39 -0500

I think extending LSR ID to 16 bytes ( and changing the version) would be better option which gives more flexibility and allows the multiple LDP sessions. So that operators can choose whether to use 4 byte or 16 byte LSR ID for Ipv6 LDP session.

Once LSR IDs are different, then there will be different adjacencies for Ipv4 and Ipv6 and need to send separate hellos. If the operator chooses 4 byte LSR ID for both Ipv4 and IPv6, then only one LDP session will be established and both Ipv4 and IPv6 hellos can go in single message with IPv6 adj capability in hello. This will help to avoid if any scaling issues.

Thanks,
Kishore

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Dutta, Pranjal K (Pranjal)
>Sent: Friday, March 02, 2012 12:02 PM
>To: Henderickx, Wim (Wim); Rajiv Asati (rajiva);
>[email-masked]
>       We shouldn't be ruling out the fact that there are some
>differences in applications of LDP compared to OSPF or BGP. If we have
>IPV6 only transport network tomorrow then applications like BGP-AD,
>Dynamic MS-PW etc has to advertise L2VPN NLRI/MS-PW NLRI etc using an
>IPV6 BGP next-hop and T-LDP has to auto-create targeted sessions. We
>can't force to set-up another ip4 network just for some applications. It
>won't be possible to map 4 byte ldp LSR-ID to the BGP IPV6 next-hop. I
>am not saying that 16 byte LSR-ID is must for LDP IPV6. It's OPTIONAL
>and adds lot of operational flexibility and better to add it now.
>
>Thanks,
>Pranjal
>
>I understand we didn't add a IPv6 router ID option in BGP/OSPF but we
>should look at the future to get to IPv6 only networks and as such it
>will be required. So we are now at a point where we should add this
>option in all protocols. Since LDP for Ipv6 is open we need to add it
>now.
>
>My 2 cents
>
>Cheers,
>Wim
>
>> > > interface IPv4 address to be chosen as router-id for various
>> > > protocols including LDP.
>> >
>> > > However, many implementations already evolved the CLI to not even
>> > > give an "interface" IP address for router-id, to accommodate IPv6.
>> > We do operate some implementations today that "still" allow you to
>> > specify the Router-ID for various protocols as an independent 32-bit
>> > integer (only), and also allow you to define the LSR-ID for LDP as
>> > an interface (only). This is current, shipping 2012 code.
>> >
>> > So both scenarios you mention above are still much in play today.
>> > Whether operators are using them or not (I know we
>> > > Now that LDP is being enhanced to use IPv6, implementations could
>> > > evolve LDP router-id as well to accommodate IPv6. This would make
>> > > LDP router-id to be consistent with other protocols delving with
>> > > IPv6. And this can certainly be operationally beneficial from IPv6
>> > > POV.
>> >
>> > Agree.
>> >
>> > > In fact, one of the implementations allow the router-id to be
>> > > configured just once and let all protocols just use it, if they
>> > > wanted.
>> >
>> > Yes, we operate some implementations that use this method too. It's
>> > quite elegant, in that you configure once and forget. Other
>> > implementations that are more structured means operators could
>> > easily forget to specify the Router-ID for a particular protocol,
>> > for better or worse.
>> >
>> > Cheers,
>> >
>> > Mark.

---

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

On Saturday, March 03, 2012 05:08:39 AM Kishore Tiruveedhula 
wrote:

> I think extending LSR ID to 16 bytes ( and changing the
> version) would be better option which gives more
> flexibility and allows the multiple LDP sessions. So
> that operators can choose whether to use 4 byte or 16
> byte LSR ID for Ipv6 LDP session.

I don't see how this would hurt, as it maintains backward 
compatibility for those who are for 32-bit LSR-ID's, and 
gives 128-bit LSR-ID fans future flexbility.

Win-win.

> Once LSR IDs are different, then there will be different
> adjacencies for Ipv4 and Ipv6 and need to send separate
> hellos. If the operator chooses 4 byte LSR ID for both
> Ipv4 and IPv6, then only one LDP session will be
> established and both Ipv4 and IPv6 hellos can go in
> single message with IPv6 adj capability in hello. This
> will help to avoid if any scaling issues.

This works for vendors who specify a global Router-ID that 
various (routing) protocols reference when starting up.

There are other vendors who specify the Router-ID (LSR-ID, 
in the case of LDP, to be pedantic) via an interface in 
their CLI. Special care would need to be taken in this 
scenario, as it would imply that if the reference interface 
(typically, the Loopback interface) is dual-stack, then 2x 
adjacencies would be formed, one per AF (on the basis of 
common sense, of course, as not doing this would indicate 
that LDPv6 code is ignoring the presence of an IPv6 address 
on the reference interface, which would be quite odd). 

However, it is possible a particular operator may prefer 
adjacency consolidation. Yes, I understand this is vendor-
implementation-specific, but I thought I'd mention it now so 
that operators have this flexibility the moment LDPv6 code 
starts shipping, rather than wait for a future upgrade which 
provides knobs for adjacency separation or consolidation.

I suppose we can leave it up to vendors which option is the 
default in their implementation, although my personal 
preference would be for adjacency separation :-).

Cheers,

Mark.

---

From: "t.petch" <[email-masked]>
Date: Sat, 3 Mar 2012 12:42:06 +0100

----- Original Message -----
From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
To: "Rajiv Asati (rajiva)" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 02, 2012 3:42 PM
> This is however a practical matter. Many deployments today have the router-id
default to a well known system loopback interface IPv4 address. This means that
routing protocols, MPLS signaling protocols,and OAM protocols can operate
directly using this address.

<tp>
Stepping back, a, if not the, major problem of the Internet, is getting people
off the somewhat overloaded IPv4.  And one of the reasons it is so difficult is
because that 32 bit dotted decimal has been used for system identifier, system
address, system locator etc etc - it is called overloading and is a surefire way
of making migration expensive, bordering on the impossible (see the RRG archives
for this lengthy discussion:-(.

So using a routable address as a router identifier was always short sighted and
dumb.  Using a separate namespace and a mapping system (ever heard of DNS or
/etc/hosts/?) is so obviously the right way to go that ...  well if you don't
get the message ...

The ancilliary point is that dotted decimal makes a 32 bit number almost user
friendly.  Anyone who thinks that a generic 128 bit number is, well ..... see
above.

I realise that if you have complete control over your address structure you can
choose a structure that reduces the number of characters to be comparable to
dotted decimal, in general you cannot, and even when you can, you have to get
those pesky double colons right - and as has been pointed already, every one of
those colons is shift on most keyboards, while those dots are not shift on most
keyboards.

So please, do not repeat the mistake of the IETF all those years ago, which so
haunts us so today.  BGP and OSPF have seen the light, with identifiers for
IPv6, and I respect their wisdom.

Tom Petch
</tp>

Certainly with BGP, the operator can configure a neighbour address which is IPv6
and is different from the router-id but that router-id is already required for
the operation of IPv4 BGP neighbours and other protocols and such this is
manageable. As we go into all IPv6 deployments, we need to have means for
deployments to have a similar default IPv6 system address. It is hardly
justifiable at that point in time to configure two different addresses to get
the prorotcols working by default. We may as well make this change now as part
of allowing separate LDP sessions for IPv4 and IPv6 or we will create yet a
third LDP version number in the next few years.

---

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

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Tinka
Sent: Friday, March 02, 2012 9:10 PM
To: Kishore Tiruveedhula
Cc: [email-masked]; [email-masked]; Aissaoui, Mustapha (Mustapha)
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Win-win.

[Pranjal] I agree. This is what we want. We shouldn't be restrictive in ldp-ipv6 draft, rather should provide options, else would hurt various current applicability scenarios on LDP which has been widely deployed.

[Pranjal] Just to clarify that "adjacency" separation does not give you fate separation. For fate separation we would need to separation of "sessions". Hello Adjacency and Session are two different concepts in LDP. The current text in the draft makes it mandatory to have two separate hello adjacencies for the same "fate shared" session. This conflicts with the way we decided to move forward with various fec types. Please refer to my reply to your other mail on the various technical reasons why I am saying so.

Cheers,

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Tue, 6 Mar 2012 11:13:07 +0800

On Tuesday, March 06, 2012 01:42:10 AM Dutta, Pranjal K 
(Pranjal) wrote:

> [Pranjal] I agree. This is what we want. We shouldn't be
> restrictive in ldp-ipv6 draft, rather should provide
> options, else would hurt various current applicability
> scenarios on LDP which has been widely deployed.

Agree.

> [Pranjal] Just to clarify that "adjacency" separation
> does not give you fate separation. For fate separation
> we would need to separation of "sessions". Hello
> Adjacency and Session are two different concepts in LDP.
> The current text in the draft makes it mandatory to have
> two separate hello adjacencies for the same "fate
> shared" session. This conflicts with the way we decided
> to move forward with various fec types. Please refer to
> my reply to your other mail on the various technical
> reasons why I am saying so.

Apologies for collapsing here, I should have been more 
explicit (operator hat, hehe).

Yes, I do mean that we make discrete both adjacencies + 
sessions to achieve a clean and clear separation of fate.

Hope this clarifies my position.

Mark.

---

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

Thanks Mark for the clarifications.

Regards,
Pranjal 

-----Original Message-----
From: Mark Tinka [mailto:[email-masked]] 
Sent: Monday, March 05, 2012 7:13 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Kishore Tiruveedhula; [email-masked]; [email-masked]; Aissaoui, Mustapha (Mustapha)
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

(Pranjal) wrote:

> [Pranjal] I agree. This is what we want. We shouldn't be restrictive 
> in ldp-ipv6 draft, rather should provide options, else would hurt 
> various current applicability scenarios on LDP which has been widely 
> deployed.

Agree.

> [Pranjal] Just to clarify that "adjacency" separation does not give 
> you fate separation. For fate separation we would need to separation 
> of "sessions". Hello Adjacency and Session are two different concepts 
> in LDP.
> The current text in the draft makes it mandatory to have two separate 
> hello adjacencies for the same "fate shared" session. This conflicts 
> with the way we decided to move forward with various fec types. Please 
> refer to my reply to your other mail on the various technical reasons 
> why I am saying so.

Apologies for collapsing here, I should have been more explicit (operator hat, hehe).

Yes, I do mean that we make discrete both adjacencies + sessions to achieve a clean and clear separation of fate.

Mark.

---

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

Mark,

> does that make things easier or harder for operators?

Thanks for putting it in a better perspective. When we eventually move
to IPv6 only paradigm, then the inconsistency would continue to be an
operational burden forever.  
	
> to be different per AF even for MP-BGP, OSPFv3 and others.

Certainly.  But as we know that the per-AF router-id turned out to be a
minority viewpoint, as 32-bit integer for the router ID was chosen for
those IPv6 protocols.

Cheers,
Rajiv

> Sent: Friday, March 02, 2012 2:11 AM
> To: Henderickx, Wim (Wim)
[email-masked];
> [email-masked]

---

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

Pranjal, Mustapha, Wim,

> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has
to
> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T-
> LDP has to auto-create targeted sessions. We can't force to set-up
another
> ip4 network just for some applications. It won't be possible to map 4
byte ldp

I hope that we are not misunderstanding 32-bit integer value in RouterID
in an IPv6-only router to mean having IPv4 network. 
Also, such applications must use 'transport IP address', not the
Router-ID when it comes to setting up the session. If they don't, then
they are incorrect and must be fixed.

Cheers,
Rajiv

> From: Dutta, Pranjal K (Pranjal)
[mailto:[email-masked]]
[email-masked]
>        We shouldn't be ruling out the fact that there are some
differences in
> applications of LDP compared to OSPF or BGP. If we have IPV6 only
transport
> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has
to
> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T-
> LDP has to auto-create targeted sessions. We can't force to set-up
another
> ip4 network just for some applications. It won't be possible to map 4
byte ldp
> LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID
is must
> for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility
and better
> to add it now.
Of
> Henderickx, Wim (Wim)
will be
> required. So we are now at a point where we should add this option in
all
> protocols. Since LDP for Ipv6 is open we need to add it now.
> 
> My 2 cents
> 
> Cheers,
> Wim
>

---

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

Tom,

> IPv6, and I respect their wisdom.

This is certainly the path we must take at minimum with ldp-ipv6 draft.

> So using a routable address as a router identifier was always short
sighted
> and dumb.  

Well, that was the easiest way out in the IPv4 paradigm. The
specification didn't intend to suggest so.
Part of blame goes to us/vendors too..

Cheers,
Rajiv

> From: t.petch [mailto:[email-masked]]
> Sent: Saturday, March 03, 2012 6:42 AM
> To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva);
> default to a well known system loopback interface IPv4 address. This
means
> that
> because that 32 bit dotted decimal has been used for system
identifier,
> system
> of making migration expensive, bordering on the impossible (see the
RRG
> archives
> So using a routable address as a router identifier was always short
sighted
> I realise that if you have complete control over your address
structure you
> can
> choose a structure that reduces the number of characters to be
comparable
> to
> dotted decimal, in general you cannot, and even when you can, you have
to
> get
> those pesky double colons right - and as has been pointed already,
every one
> of
> those colons is shift on most keyboards, while those dots are not
shift on
> most keyboards.
> Certainly with BGP, the operator can configure a neighbour address
which is
> IPv6
> the prorotcols working by default. We may as well make this change now
as
> part

---

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

Rajeev,

Not really. There are applications that auto-instantiate T-LDP sessions. 
You know transport address only after exchanging hellos. First hellos need
to be sent to right remote LSR-ID. We don't run another discovery protocol 
that says "here is the BGP next-hop X  but its LSR-ID is Y". Are you suggesting that all such applications are irrelevant and needs to be wiped
out from deployments. I haven't heard of any text in RFC 5036 that says 
"4 byte router-id MUST not be a routable address".

Cheers,
Pranjal 

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

Pranjal, Mustapha, Wim,

to
another
byte ldp

Cheers,
Rajiv

[email-masked]
differences in
transport
to
another
byte ldp
is must
and better
Of
will be
all

---

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

Pranjal,

> to be sent to right remote LSR-ID. 

Hellos should be sent to the correct transport address (unicast or
multicast), not to the chosen LSR-ID.
 
Cheers,
Rajiv

> Sent: Monday, March 12, 2012 12:45 PM
> To: Rajiv Asati (rajiva); Henderickx, Wim (Wim);
[email-masked]
> that says "here is the BGP next-hop X  but its LSR-ID is Y". Are you
suggesting
> that all such applications are irrelevant and needs to be wiped
Of
Behalf
> > > I take that we are in agreement wrt 4-octet entity for LDP
router-id

---

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

Rajiv,
          How would you solve the following:

<We don't run another discovery
Protocol that says "here is the BGP next-hop X  but its LSR-ID is Y".>

Cheers,
Pranjal

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

Pranjal,

 
Cheers,
Rajiv

[email-masked]
suggesting
Of
Behalf
router-id

---

From: Kamran Raza <[email-masked]>
Date: Mon, 12 Mar 2012 16:29:31 -0500

Pranjal,

> I haven't heard of any text in RFC 5036 that says

At the same time, the RFC 5036 does not specify 4 byte LSR-Id as an IP
address, let alone "routable" address. Does it ?

RF 5036, section 2.2.2.:

"The first four octets identify the LSR and must be a
   globally unique value, such as a 32-bit router Id assigned to the
   LSR. 
"

The implementations took easy way out and started using it as:
  i) an IPv4 address, and
  ii) an address that is routable
  
While one can try to justify this interpretation for IPv4, not sure how can
we justify this for IPv6.

As I had said earlier, transport connection endpoints and/or targeted hello
destinations should be discovered through other LDP protocol/cfg means,
instead of "infering" it from LSR-ID part of LDP-Identifier.

My 2 cents.

On 12-03-12 11:44 AM, "Dutta, Pranjal K (Pranjal)"
<[email-masked]> wrote:

> suggesting that all such applications are irrelevant and needs to be wiped

-- 
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: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 13 Mar 2012 02:04:11 +0530

Hi Kamran,

I don't agree. When RFC 5036 is ambiguous (does not say LSR MUST NOT be routable) then you can't say the following as mandate.

"As I had said earlier, transport connection endpoints and/or targeted hello
destinations should be discovered through other LDP protocol/cfg means,
instead of "infering" it from LSR-ID part of LDP-Identifier."

Cheers,
Pranjal

-----Original Message-----
From: Kamran Raza [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 2:30 PM
To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim); [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

RF 5036, section 2.2.2.:

  

My 2 cents.

---

From: Kamran Raza <[email-masked]>
Date: Mon, 12 Mar 2012 17:25:17 -0500

Pranjal,

1. I was not mandating anything. I'd used "should" ;-)

2. I did not find the LSR-Id description ambiguous in RFC 5036.
The description clearly says it is just a 32-bit identifier;
Now it is a different story that some implementation chose to interpret it
as an IPv4 address (for operational-ease reasons), and other implementations
had to follow in order to inter-op.

In a nutshell, while I see the value of this interpretation in IPv4 env, I
do not think that we need to carry forward this notion onward (which is
ambiguous - according to some - to begin with).

Rgds.

-- Kamran

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

> Hi Kamran,
> 
> I don't agree. When RFC 5036 is ambiguous (does not say LSR MUST NOT be
> routable) then you can't say the following as mandate.
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 13 Mar 2012 03:22:56 +0530

Kamran,
        Let me clarify a few things. Nobody in this mailing list (including me) ever suggested for ipv6 based LSR-ID to be made mandatory for IPV6 deployments, rather suggested to add as an OPTIONAL since making the lsr-id 
routable has been providing tremendous operational simplicity on gluing co-existing network applications. There are several arguments that had been provided on that in the list. You are right while saying as below:

>   ii) an address that is routable

Yes, it makes lot of things easy and such implementations have been providing lot of operational benefits to operators in various deployed solutions. 

    We are working towards progressing a technology and decision should be based on what makes operationally more sensible, rather than going by just puritanical references alone. RFC 5036 never says that its procedures should never be extended. We have done numerous extensions to LDP in several other drafts/RFCs post RFC 3036/5036. Let's assume for now that as per your view RFC 5036 is super-perfect and there is no ambiguity, then still I won't keep a dogmatic view of RFC 5036 and would go ahead and vote for IPV6 based LSR-ID (LDP v2). Such judgment is based on operational benefits its going to incur for a huge bunch of network applications when deployed in IPV6 only networks. Then what surprises me is that why we are so resistive when we
are suggesting 16 byte LSR-ID as OPTIONAL method for IPV6 deployments?  
Does any inter-operability breaks by keeping ipv6 based LSR-ID as OPTIONAL?  

Cheers,
Pranjal

-----Original Message-----
From: Kamran Raza [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 3:25 PM
To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim); [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,

Rgds.

-- Kamran

---

From: Kamran Raza <[email-masked]>
Date: Mon, 12 Mar 2012 18:13:58 -0500

As I understand, all this LSR-Id discussion is in the context of
establishing/maintaining separate LDP sessions for IPv4 and IPv6. [ Please
correct me if I am mistaken, or have missed something else in this lllong
email thread ]. 

If this understanding holds, then Let's park this debate until we first
close on the other more significant item regarding separate LDP sessions for
IPv4 and IPv6.

Rgds.

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

> Kamran,
>         Let me clarify a few things. Nobody in this mailing list (including
> me) ever suggested for ipv6 based LSR-ID to be made mandatory for IPV6
> deployments, rather suggested to add as an OPTIONAL since making the lsr-id
> routable has been providing tremendous operational simplicity on gluing
> co-existing network applications. There are several arguments that had been
> provided on that in the list. You are right while saying as below:
> 
> Yes, it makes lot of things easy and such implementations have been providing
> lot of operational benefits to operators in various deployed solutions.
> 
>     We are working towards progressing a technology and decision should be
> based on what makes operationally more sensible, rather than going by just
> puritanical references alone. RFC 5036 never says that its procedures should
> never be extended. We have done numerous extensions to LDP in several other
> drafts/RFCs post RFC 3036/5036. Let's assume for now that as per your view RFC
> 5036 is super-perfect and there is no ambiguity, then still I won't keep a
> dogmatic view of RFC 5036 and would go ahead and vote for IPV6 based LSR-ID
> (LDP v2). Such judgment is based on operational benefits its going to incur
> for a huge bunch of network applications when deployed in IPV6 only networks.
> Then what surprises me is that why we are so resistive when we
>>> Asati (rajiva)

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 13 Mar 2012 03:58:21 +0530

It is not completely attached to fate separation subject although it is an inherent component for fate separation. If a network is ipv6 transport only then IPV6 based LSR-ID provides lot of operational simplicity in various solutions, even though operator may have no strong case for fate separation.

Cheers,
Pranjal

-----Original Message-----
From: Kamran Raza [mailto:[email-masked]]
Sent: Monday, March 12, 2012 4:14 PM
To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim); [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Rgds.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 13 Mar 2012 17:46:25 -0500

Hi Pranjal,

rfc6074 solves it well enough. I request you to refer to the following
sections:

http://tools.ietf.org/html/rfc6074#section-3.3.3
http://tools.ietf.org/html/rfc6074#section-3.2.3

No router-id / LSR id relevance here, suffice to say. A PE router
involved in BGP AD (say) would use the IPv4|IPv6 address conveyed by BGP
nh for the subsequent LDP signaling.

I would be glad to clarify further, if needed. Thanks.

Cheers,
Rajiv

> Sent: Monday, March 12, 2012 1:32 PM
[email-masked]
> > You know transport address only after exchanging hellos. First
hellos
> need
> > You know transport address only after exchanging hellos. First
hellos
> need
> > > ip4 network just for some applications. It won't be possible to
map
> 4
> > > ip4 network just for some applications. It won't be possible to
map
> 4
Behalf
> > > previous email, the router-id consistency across protocols would
be
> an
> > > the uniqueness? If so, then it would be worth having that
discussion
> > > if we expanded it for the sake of it, but didn't address the root
of
> > > > If we do not introduce the IPv6 LSR ID now I will be very hard
to
> ad

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 14 Mar 2012 05:43:09 +0530

Hi Rajiv,
           Deriving LSP LSR-ID from PE_Addr part of L2VPN NLRI is one way for BGP-AD but that can't be generalized since same doesn't apply for Dynamic MS-PW NLRI type (AII Type 2).

http://tools.ietf.org/html/rfc5003#section-3.2

T-PE1------S-PE2-------S-PE3------T-PE2

The T-PE1 won't have direct T-LDP session to T-PE2 that originated the AII Type 2 = AGI:Global-Id:Prefix:AC-ID, rather would have T-LDP session with 
S-PE2 only. So T-PE1 can't derive router-id part of LDP LSR-ID from the 
Prefix advertised by T-PE2. 

On the same note, issue would be applicable when dynamic MS-PW is used for provisioning BGP-AD (with AII Type 1 without aggregation of prefix). In such a case there won't be a direct T-LDP sessions between T-PEs hosting the VSI for BGP-AD (or the T-PEs that originated the L2VPN NLRI). 

Cheers,
Pranjal 

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2012 3:46 PM
To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); [email-masked]
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Pranjal,

Cheers,
Rajiv

[email-masked]
hellos
hellos
map
map
Behalf
be
discussion
of
to