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

From: Lizhong Jin<[email-masked]>
Date: Tue, 7 Feb 2012 11:22:49 +0800

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: Kamran Raza <[email-masked]>
Date: Mon, 06 Feb 2012 23:49:49 -0500

Hi Lizhong,

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

 1. LDP capabilities are advertised on peer/session level and do not
correspond to adj capabilities.
 2. An LSR must not be forwarding MPLS on an interface unless/until it has
got an MPLS adj on it  extending the same to address families, an LSR must
not forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [
Single adj will not convey us remote node¹s interface capability for given
AF, and it will be incorrect to forward 6 MPLS labelled traffic on it unless
we know that remote intf is v6 MPLS enabled ]

 My 2 cents.
-- Kamran

On 12-02-06 10:22 PM, "Lizhong Jin" <[email-masked]> wrote:

> 
> Hi, 
> I wonder if it is feasible to use LDP capability to advertise IPv6 FEC without
> IPv6 adjacency, and only use one adjacency for LDP session in dual-stack
> network. LDP capability is per node capability, not per interface capability.
> But for LDP to choose the correct downstream session and output interface for
> each FEC, it should also check if the output interface is LDP enabled or not.
> The link adjacency could be used to assist such kind of checking.
> 
> [Kamran]:
> 
> However, IMO, it is valuable to allow two independent LDP sessions for IPv4
> and IPv6 as an option. Regarding the format definition in RFC5036, we may need
> new LDP version number to identify IPv6 LSR-ID. Or we use different 32bit
> LSR-ID for IPv6 with IPv4, but I prefer new format of LSR-ID.
> 
> Regards 
> Lizhong 
> 
> 
>> > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> 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.
> _______________________________________________
> 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: Lizhong Jin<[email-masked]>
Date: Tue, 7 Feb 2012 13:46:54 +0800

Hi Kamran,
I Agree. And draft-ietf-mpls-ldp-ipv6-06 section 7 says:  Another solution 
for getting the same result as above is by negotiating the IP Capability 
for a given AFI, as specified in [IPPWCap]. Such wording is incorrect, 
because the result of IPv4 and IPv6 Hello Adjacencies and IP Capability 
for a given AFI is different. IPv6 Hello Adjacencies could not be replaced 
by LDP IP Capability.

Thanks
Lizhong

Kamran Raza <[email-masked]> wrote 2012/02/07 12:49:49:

> Hi Lizhong,
> 
> Using single adj [ and just checking local interface enabling for 
> given AF + capabilities ] will not suffice/work because:
> 
>  2. An LSR must not be forwarding MPLS on an interface unless/until 
> it has got an MPLS adj on it – extending the same to address 
> families, an LSR must not forward MPLS v6 on an interface unless it 
> has got MPLS v6 adj on it. [ Single adj will not convey us remote 
> node’s interface capability for given AF, and it will be incorrect 
> to forward 6 MPLS labelled traffic on it unless we know that remote 
> intf is v6 MPLS enabled ]
> 
>  My 2 cents.
> -- Kamran
> 

> 
> Hi, 
> I wonder if it is feasible to use LDP capability to advertise IPv6 
> FEC without IPv6 adjacency, and only use one adjacency for LDP 
> session in dual-stack network. LDP capability is per node 
> capability, not per interface capability. But for LDP to choose the 
> correct downstream session and output interface for each FEC, it 
> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking. 
> 
> [Kamran]:
> 
> However, IMO, it is valuable to allow two independent LDP sessions 
> for IPv4 and IPv6 as an option. Regarding the format definition in 
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer 
> new format of LSR-ID. 
> 
> Regards 
> Lizhong 
> 
> 
IPV6.
impacts.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 7 Feb 2012 09:03:09 -0600

Kamran,
in LDP, the ability to advertise a FEC type between peers is independent of the adjacency established. I am not sure why this was not an issue for other FEC types (unicast IPv4 FEC, PW FEC, mLDP p2mp FEC) and it is now for unicast IPv6 FEC prefixes. The user controls which prefix type to advertize/accept to/from a peer via import/export policies and LDP node capability advertisement.

You point 2 below is about FEC resolution and not FEC advertisement. When you resolve a FEC, you need to check which LSR-id owns the next-hop in the routing table for the IPv6 prefix and this is provided by the list of interface addresses in the Address List TLV. If you have received a label for the FEC from the LSR-id which owns the IPv6 next-hop, you can resolve the FEC to that interface even if the Hello adjacency over that interface is IPv4 only.

We need to keep that separation between FEC advertisement and adjacency type for backward compatibility with RFC 5036. What we need in my view is to relax RFC 5036 to allow the setup of multiple LDP adjacencies/sessions between two LSRs which use two different LSR-id but the same global label-space-id. This can be done with some rules to avoid loops. Users will then be free to dedicate an LDP session for IPv6 prefixes and another for IPv4 prefixes much like the BGP model allows for.

Regards,
Mustapha.

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

Hi Lizhong,

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

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

 My 2 cents.
-- Kamran

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

[Kamran]:

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

Regards
Lizhong

> egress traffic but I see it as overkill and unnecessary scalability impacts.
>
> Thanks,
> Pranjal
>

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

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 7 Feb 2012 09:11:52 -0600

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 IPv6 addresses.

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,

Regards
Lizhong

---

From: Kamran Raza <[email-masked]>
Date: Tue, 07 Feb 2012 10:52:06 -0500

Hi Mustapha,

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

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

>> Your point 2 below is about FEC resolution and not FEC advertisement
That¹s right. I¹d read the proposal from Lizhong as using ³single² adjacency
for both v4/v6, and I don¹t think that coupling v4/v6 [ link] state to a
single adjacency is right thing to do [ re: FEC resolution/fwding setup ]

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

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

My 2 cents.

On 12-02-07 10:03 AM, "Aissaoui, Mustapha (Mustapha)"
<[email-masked]> wrote:

> Kamran,
> in LDP, the ability to advertise a FEC type between peers is independent of
> the adjacency established. I am not sure why this was not an issue for other
> FEC types (unicast IPv4 FEC, PW FEC, mLDP p2mp FEC) and it is now for unicast
> IPv6 FEC prefixes. The user controls which prefix type to advertize/accept
> to/from a peer via import/export policies and LDP node capability
> advertisement.
>  
> You point 2 below is about FEC resolution and not FEC advertisement. When you
> resolve a FEC, you need to check which LSR-id owns the next-hop in the routing
> table for the IPv6 prefix and this is provided by the list of interface
> addresses in the Address List TLV. If you have received a label for the FEC
> from the LSR-id which owns the IPv6 next-hop, you can resolve the FEC to that
> interface even if the Hello adjacency over that interface is IPv4 only.
>  
> We need to keep that separation between FEC advertisement and adjacency type
> for backward compatibility with RFC 5036. What we need in my view is to relax
> RFC 5036 to allow the setup of multiple LDP adjacencies/sessions between two
> LSRs which use two different LSR-id but the same global label-space-id. This
> can be done with some rules to avoid loops. Users will then be free to
> dedicate an LDP session for IPv6 prefixes and another for IPv4 prefixes much
> like the BGP model allows for.
>  
> Regards,
> Mustapha.
> 
> 
>  2. An LSR must not be forwarding MPLS on an interface unless/until it has got
> an MPLS adj on it  extending the same to address families, an LSR must not
> forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [ Single
> adj will not convey us remote node¹s interface capability for given AF, and it
> will be incorrect to forward 6 MPLS labelled traffic on it unless we know that
> remote intf is v6 MPLS enabled ]
> 
>  My 2 cents.
> -- Kamran
> 
>> dual-stack network. LDP capability is per node  capability, not per interface
>> capability. But for LDP to choose the correct  downstream session and output
>> interface for each FEC, it should also check if  the output interface is LDP
>> enabled or not. The link adjacency could be used  to assist such kind of
>> checking. 
>> 
>> [Kamran]:
>> 
>> 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  
>> 
>> 
>> confidential. Recipients named above are obligated to maintain secrecy and
>> are  not permitted to disclose the contents of this communication to  others.
>> 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

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 7 Feb 2012 12:30:42 -0600

Hi Kamran,
I agree that LDP capability is good to have and I support that work. It however does not solve the issue at hand.

I did not follow the discussions but what were the main objections to multiple adjacencies for the same label space? If not that then we are only left with the virtualization of LDP to create multiple global label spaces.

Mustapha.

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

Hi Mustapha,

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

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

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

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

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

My 2 cents.

On 12-02-07 10:03 AM, "Aissaoui, Mustapha (Mustapha)" <[email-masked]> wrote:

Kamran,

Regards,
Mustapha.

Hi Lizhong,

 My 2 cents.
-- Kamran

Hi,

[Kamran]:

Regards
Lizhong

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 8 Feb 2012 00:10:31 +0530

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

Thanks,
Pranjal

Sent: Monday, February 06, 2012 8:50 PM

Hi Lizhong,

 1. LDP capabilities are advertised on peer/session level and do not correspond to adj capabilities.
 2. An LSR must not be forwarding MPLS on an interface unless/until it has got an MPLS adj on it - extending the same to address families, an LSR must not forward MPLS v6 on an interface unless it has got MPLS v6 adj on it. [ Single adj will not convey us remote node's interface capability for given AF, and it will be incorrect to forward 6 MPLS labelled traffic on it unless we know that remote intf is v6 MPLS enabled ]

 My 2 cents.
-- Kamran

Hi,

[Kamran]:

Regards
Lizhong

---

From: Lizhong Jin<[email-masked]>
Date: Wed, 8 Feb 2012 10:24:58 +0800

Pranjal,
See inline below.

Thanks
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 
2012/02/08 02:40:31:

> Hi,
>       Using separate adjacency to decide capabilities on an 
> interface would kick start several wars as the issue not just 
> limited to IPV4 vs IPV6. The same is applicable to multicast 
> capabilities as well when an operator may have multiple ECMP links 
> between two nodes but certain links/cards do not have multicast 
> capabilities. 
[Lizhong] Theoretically, you are right. And ususally we assume LDP enabled 
interface also support multicast if LDP session is multicast enabled, but 
yes, such assumption has risk.

> This is just one example and we have more such 
> capabiities. So as of now such link specific restrictions should be 
> imposed by local behaviors rather than coupling with adjacency 
> types. 
[Lizhong] Restriction checking based on local capability is not enough, 
and having capability risk of peer interface.

> Otherwise LDP capabilities should be extended to be used in 
> per interface ldp hello messages where a single adjacency would be 
> tagged multiple capabilities. 
[Lizhong] LDP capability based on per adjacency is a feasible approach, 
and if that, we need to change RFC5561.

> I would believe that is more rightful 
> approach than maintaining separate hellos adjacencies for each 
> capability that would grow exponentially at some point. 
> 
> Thanks,
> Pranjal
> 
> 
> 
IPV6.
impacts.

---

From: Lizhong Jin<[email-masked]>
Date: Wed, 8 Feb 2012 10:48:17 +0800

Hi
> platform-wide label space) between two LSRs has been 
> proposed/discussed in IETF WGs [ MPLS/PWE3] before as well (e.g. 
> ICCP), but was rejected.
[Lizhong] I think the requirement of two sessions for IPv4 and IPv6 is 
different with the case of ICCP. This is related with current dual-stack 
IPv4/v6 deployment and operations as Shane mentioned.

Thanks
Lizhong

> 
> If I’ve to chose between Capabilities based solution and Separate 
> LDP session to support IPv4/IPv6 LDP, I will go with LDP 
> Capabilities based solution.
> 
> My 2 cents.
> 

> Kamran,
> in LDP, the ability to advertise a FEC type between peers is 
> independent of the adjacency established. I am not sure why this was
> not an issue for other FEC types (unicast IPv4 FEC, PW FEC, mLDP 
> p2mp FEC) and it is now for unicast IPv6 FEC prefixes. The user 
> controls which prefix type to advertize/accept to/from a peer via 
> import/export policies and LDP node capability advertisement.
> 
> You point 2 below is about FEC resolution and not FEC advertisement.
> When you resolve a FEC, you need to check which LSR-id owns the 
> next-hop in the routing table for the IPv6 prefix and this is 
> provided by the list of interface addresses in the Address List TLV.
> If you have received a label for the FEC from the LSR-id which owns 
> the IPv6 next-hop, you can resolve the FEC to that interface even if
> the Hello adjacency over that interface is IPv4 only. 
> 
> We need to keep that separation between FEC advertisement and 
> adjacency type for backward compatibility with RFC 5036. What we 
> need in my view is to relax RFC 5036 to allow the setup of multiple 
> LDP adjacencies/sessions between two LSRs which use two different 
> LSR-id but the same global label-space-id. This can be done with 
> some rules to avoid loops. Users will then be free to dedicate an 
> LDP session for IPv6 prefixes and another for IPv4 prefixes much 

> should also check if  the output interface is LDP enabled or not. 
> 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 
> 
> 
IPV6.
> -----

---

From: Kishore Tiruveedhula <[email-masked]>
Date: Wed, 8 Feb 2012 10:33:09 -0500

I think, if new IPv6 family TLV added in the Hello message, then you don't need to send separate hello for IPv6.  It is kind of combining both Ipv4 and Ipv6 hellos into single Hello.

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

Thanks,
Kishore

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kamran Raza
Sent: Monday, February 06, 2012 11:50 PM
To: Lizhong Jin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Lizhong,

 My 2 cents.
-- Kamran

Hi,

[Kamran]:

Regards
Lizhong

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 8 Feb 2012 22:43:20 +0530

Yes, adjacency specific capability exchange in hello would be right approach for IPV4 + IPV6 and need to extend the work of RFC 5561.
The ldp-ipv6 draft should change the text on multiple adjacency behaviour on dual stack and should refer to the per adjacency specific ldp
capabilities.

Thanks,
Pranjal

________________________________
From: Lizhong Jin [mailto:[email-masked]]
Sent: Tuesday, February 07, 2012 6:25 PM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]; Aissaoui, Mustapha (Mustapha); Kamran Raza; [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Pranjal,
See inline below.

Thanks
Lizhong

> between two nodes but certain links/cards do not have multicast
[Lizhong] Theoretically, you are right. And ususally we assume LDP enabled interface also support multicast if LDP session is multicast enabled, but yes, such assumption has risk.

> imposed by local behaviors rather than coupling with adjacency
[Lizhong] Restriction checking based on local capability is not enough, and having capability risk of peer interface.

> tagged multiple capabilities.
[Lizhong] LDP capability based on per adjacency is a feasible approach, and if that, we need to change RFC5561.

> it has got an MPLS adj on it - extending the same to address
> node's interface capability for given AF, and it will be incorrect

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 8 Feb 2012 22:54:50 +0530

Yes that would be right approach. Changing the LSR-ID would further open more backward compatibility issues with existing implementations.

Thanks,
Pranjal

________________________________
From: Aissaoui, Mustapha (Mustapha)
Sent: Tuesday, February 07, 2012 7:12 AM
To: Lizhong Jin; Dutta, Pranjal K (Pranjal); [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Lizhong,

Mustapha.

Hi,

Regards
Lizhong

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 29 Feb 2012 14:35:41 -0600

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,

Mustapha.

Hi,

Regards
Lizhong

---

From: Lizhong Jin<[email-masked]>
Date: Thu, 1 Mar 2012 08:57:25 +0800

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.

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

IPV6.
impacts.
> 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.

---

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

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

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

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 29 Feb 2012 17:11:13 -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?

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,
> > This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.****
>
>

---

From: Kamran Raza <[email-masked]>
Date: Wed, 29 Feb 2012 23:39:44 -0500

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:

> 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:
>> 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
>>  
>> 
>> 
>>>> > > alcatel-lucent.com <http://alcatel-lucent.com> >
>>>> > >    
>>> system.