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

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 3 Feb 2012 17:12:15 -0600

Dear authors,
below are comments on this draft. I realize this draft passed WG last call but I think the issues are significant enough in my view. I apologize if some of these comments were already raised on this mailing list.
 
Regards,
Mustapha.
=======================================================================================

1. Section 3 - LSP Mapping; second paragraph.
MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring to a loopback interface of the egress router, not any other interface. That is why RFC 5036 explicitly states /32 for IPv4. In my view, we should explicitly refer to /128 for IPv6.

2. Section 3 - LSP Mapping; last Paragraph:
"
Additionally, it is desirable that a packet is forwarded to an LSP of an egress router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches with that of the LDP hello adjacency on the next-hop interface.
" 
MA> RFC 5036 makes no tie, and there should not be, between the type of resolved FEC and the adjacency to the next-hop. I think this statement should be removed. 

3. Section 4 - LDP identifiers; third paragraph:
"
This document qualifies the first sentence of last paragraph of
   Section 2.5.2 of [RFC5036] to be per address family and therefore
   updates that sentence to the following: "For a given address family
   over which a Hello is sent, and a given label space, an LSR MUST
   advertise the same transport address." This rightly enables the per-
   platform label space to be shared between IPv4 and IPv6.
"
MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has anything to do with the address family. It only requires that an LSR advertises the same transport address in all Hello adjacencies that advertise the same label space. In fact the intent as explained in the second sentence of that same paragraph was to make sure that if two LSRs are establishing multiple Hello adjacencies that they play the same active/passive role for establishing the TCP connection. 

In practice though, most implementations allow Hello adjacencies over parallel links with different IPv4 transport addresses and it works just fine. I think we should remove this restriction from RFC 5036 and not refer to it in this draft.

4. Section 5.1 - Basic Discovery mechanism
MA> I understand the need to send both IPv4 and IPv6 Hello messages over a dual-stack interface since there could be both IPv4 and IPv6 LSRs on the same subnet. However, this does not justify the need to maintain two separate Hello ajacencies per peer. In practice, each router can send both IPv4 and IPv6 hellos but only a single Hello adjacency must be allowed with each peer (LSR-id, label-space} over a given interface, whichever came up first. Over a P2P interface, it is up to the user to configure which adjacency they want to form which means there is only a need to send one type of hello.

5. Section 6.1 - Transport connection establishment
"
2. An LSR SHOULD accept the Hello message that contains both IPv4
        and IPv6 transport address optional objects, but MUST use only
        the transport address whose address family is the same as that
        of the IP packet carrying Hello.
"
MA> This is not a new issue. If I am not mistaken, this can also occur in RFC 5036 implementations if an LSR receives two optional IPv4 transport address TLVs. RFC 506 does not say what to do with this and was left for implementations to handle. If we absolutely need to specify something, maybe we should say only the first TLV in the Hello message is processed.  

6. Section 6.1 - Transport connection establishment
"
7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new
        LDP session with a remote LSR, if it has both IPv4 and IPv6
        hello adjacencies for the same LDP Identifier (over a dual-
        stack interface, or two or more single-stack IPv4 and IPv6
        interfaces). This applies to the section 2.5.2 of RFC5036.

8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new
        LDP session with a remote LSR, if they attempted two TCP
        connections using IPv4 and IPv6 transport addresses
        simultaneously.
"
MA> No need for all this if you enforce that only a single adjacency is maintained to each peer over a dual-stack interface.

7. Section 7 - Label Distribution; First paragraph:
"
An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as
   well as interface addresses via ADDRESS message) from/to the peer
   over an LDP session (using whatever transport), unless it has valid
   IPv4 and IPv6 Hello Adjacencies for that peer, as specified in
   section 6.2.
"
MA> I do not agree that the advertisement of IPv6 label-FEC bindings should depend on the existence of an IPv6 Hello adjacency. This is a very narrow interpretation of RFC 5036. 
The proper solution to this is to add an IPV6 LDP capability to negotiate which FEC address family can be exchanged regardless if the Hello adjacency is IPv4 or IPv6. This is already done for multicast LDP (mLDP) FECs.

8. Section 7 - Label Distribution; Fourth paragraph:
"
Additionally, to ensure backward compatibility (and interoperability with IPv4-only LDP implementations), this document specifies that 
- 1. An LSR MUST NOT send a label mapping message with a FEC TLV containing FEC Elements of different address-family. In other words, a FEC TLV in the label mapping message MUST contain the FEC Elements belonging to the same address-family. 
2. An LSR MUST NOT send an Address message (or Address Withdraw message) with an Address List TLV containing IP addresses of different address-family. In other words, an Address List TLV in the Address (or Address Withdraw) message MUST contain the addresses belonging to the same address-family..
"
MA> This is yet another narrow interpretation of RFC 5036. There is no justification for such a restriction and certainly RFC 5036 does not make it. A FEC TLV contains list of FEC Elements which are opaque. Each FEC Element has its own Type, Length, Value and is self sufficient. Although implementations don't mix and match FEC elements but they are designed to handle it. Same applies to Address list  TLV. 

9. Section 8 - LDP Identifiers and Next Hop Addresses
MA> I believe the need to handle duplicate interface addresses received from two different peers is not a new issue. It needed to be handled in existing IPv4 based LDP implementations. Maybe the authors can specify why duplicate link local addresses is any different.

10. Section 9 - LDP TTL Security
"
This document also specifies that the LDP/TCP transport connection
   over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security
   Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP
   session peering established between the adjacent LSRs using Basic
   Discovery, by default.
"
MA> GTSM must be optional as explained in RFC 5082. This draft is not defining a new protocol and as such it should remain optional as in RFC 5036.

=======================================================================================

---

From: Shane Amante <[email-masked]>
Date: Fri, 3 Feb 2012 21:32:12 -0700

Mustapha,

I am not an author, but I do want to provide some operational input on some of your comments.  Specifically, I get the sense from several of your comments -- actually, moreso from #3 -- that you are opposed to maintaining separate LDP Hello and/or Session Adjacencies: 1 for each address family.  (If my impression is incorrect I apologize).

I actually *do* want to have separate LDP Hello and Session adjacencies: one per address family, at least at this point in time. I'm concerned about [operational] issues that may develop in, for example, v6 affecting the exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one more concrete example, 6man/v6ops are only right now working on improving the robustness of IPv6 ND to DoS attacks. There are potentially other areas where IPv6 will be hardened, as well. The bottom-line is I do not want problems in v6 to affect exchange of FEC's + labels for v4, or vice-versa. Also, FWIW, there has already been a precedent here wrt BGP where there it maintains separate neighbors/sessions for each address family, so why aren't we doing the same thing for LDP?

Ultimately, having separate sessions over-the-wire is much more intuitive to operators in lots of cases where they may expect that a configuration change or bugs they /think/ are only going to affect one address family, really do only affect one address family. Besides, LDP Hello & Sessions timers, when set to default, are extremely relaxed (order of several seconds), so the burden on implementations to maintain separate sessions should be miniscule.

IMO, I would prefer that the default be separate Hellos & Sessions over the wire to avoid "fate sharing". Only when an operator chooses to explicitly configure their device to have hellos and sessions share fate should the device do so.

Just my $0.02,

-shane

On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Phil Bedard <[email-masked]>
Date: Mon, 06 Feb 2012 10:59:16 -0500

As an operator I second this opinion.  Providers using IS-IS as a V4/V6
IGP generally separate those processes and maintain different adjacencies
even though IS-IS is capable of both.

Phil 

On 2/3/12 11:32 PM, "Shane Amante" <[email-masked]> wrote:

>Mustapha,
>
>I am not an author, but I do want to provide some operational input on
>some of your comments.  Specifically, I get the sense from several of
>your comments -- actually, moreso from #3 -- that you are opposed to
>maintaining separate LDP Hello and/or Session Adjacencies: 1 for each
>address family.  (If my impression is incorrect I apologize).
>
>I actually *do* want to have separate LDP Hello and Session adjacencies:
>one per address family, at least at this point in time. I'm concerned
>about [operational] issues that may develop in, for example, v6 affecting
>the exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one
>more concrete example, 6man/v6ops are only right now working on improving
>the robustness of IPv6 ND to DoS attacks. There are potentially other
>areas where IPv6 will be hardened, as well. The bottom-line is I do not
>want problems in v6 to affect exchange of FEC's + labels for v4, or
>vice-versa. Also, FWIW, there has already been a precedent here wrt BGP
>where there it maintains separate neighbors/sessions for each address
>family, so why aren't we doing the same thing for LDP?
>
>Ultimately, having separate sessions over-the-wire is much more intuitive
>to operators in lots of cases where they may expect that a configuration
>change or bugs they /think/ are only going to affect one address family,
>really do only affect one address family. Besides, LDP Hello & Sessions
>timers, when set to default, are extremely relaxed (order of several
>seconds), so the burden on implementations to maintain separate sessions
>should be miniscule.
>
>IMO, I would prefer that the default be separate Hellos & Sessions over
>the wire to avoid "fate sharing". Only when an operator chooses to
>explicitly configure their device to have hellos and sessions share fate
>should the device do so.
>
>Just my $0.02,
>
>-shane
>
>
>
>> below are comments on this draft. I realize this draft passed WG last
>>call but I think the issues are significant enough in my view. I
>>apologize if some of these comments were already raised on this mailing
>>list.
>> 
>> Regards,
>> Mustapha.
>> 
>> MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring to a
>>loopback interface of the egress router, not any other interface. That
>>is why RFC 5036 explicitly states /32 for IPv4. In my view, we should
>>explicitly refer to /128 for IPv6.
>> 
>> 
>> Additionally, it is desirable that a packet is forwarded to an LSP of
>>an egress router, only if LSP's address-family (e.g. LSPv4 or LSPv6)
>>matches with that of the LDP hello adjacency on the next-hop interface.
>> " 
>> MA> RFC 5036 makes no tie, and there should not be, between the type of
>>resolved FEC and the adjacency to the next-hop. I think this statement
>>should be removed.
>> 
>> 
>> MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has
>>anything to do with the address family. It only requires that an LSR
>>advertises the same transport address in all Hello adjacencies that
>>advertise the same label space. In fact the intent as explained in the
>>second sentence of that same paragraph was to make sure that if two LSRs
>>are establishing multiple Hello adjacencies that they play the same
>>active/passive role for establishing the TCP connection.
>> 
>> In practice though, most implementations allow Hello adjacencies over
>>parallel links with different IPv4 transport addresses and it works just
>>fine. I think we should remove this restriction from RFC 5036 and not
>>refer to it in this draft.
>> 
>> 
>> MA> I understand the need to send both IPv4 and IPv6 Hello messages
>>over a dual-stack interface since there could be both IPv4 and IPv6 LSRs
>>on the same subnet. However, this does not justify the need to maintain
>>two separate Hello ajacencies per peer. In practice, each router can
>>send both IPv4 and IPv6 hellos but only a single Hello adjacency must be
>>allowed with each peer (LSR-id, label-space} over a given interface,
>>whichever came up first. Over a P2P interface, it is up to the user to
>>configure which adjacency they want to form which means there is only a
>>need to send one type of hello.
>> 
>> 
>> MA> This is not a new issue. If I am not mistaken, this can also occur
>>in RFC 5036 implementations if an LSR receives two optional IPv4
>>transport address TLVs. RFC 506 does not say what to do with this and
>>was left for implementations to handle. If we absolutely need to specify
>>something, maybe we should say only the first TLV in the Hello message
>>is processed.  
>> 
>> 
>> MA> No need for all this if you enforce that only a single adjacency is
>>maintained to each peer over a dual-stack interface.
>> 
>> 
>> MA> I do not agree that the advertisement of IPv6 label-FEC bindings
>>should depend on the existence of an IPv6 Hello adjacency. This is a
>>very narrow interpretation of RFC 5036.
>> The proper solution to this is to add an IPV6 LDP capability to
>>negotiate which FEC address family can be exchanged regardless if the
>>Hello adjacency is IPv4 or IPv6. This is already done for multicast LDP
>>(mLDP) FECs.
>> 
>> 
>> Additionally, to ensure backward compatibility (and interoperability
>>with IPv4-only LDP implementations), this document specifies that
>> - 1. An LSR MUST NOT send a label mapping message with a FEC TLV
>>containing FEC Elements of different address-family. In other words, a
>>FEC TLV in the label mapping message MUST contain the FEC Elements
>>belonging to the same address-family.
>> 2. An LSR MUST NOT send an Address message (or Address Withdraw
>>message) with an Address List TLV containing IP addresses of different
>>address-family. In other words, an Address List TLV in the Address (or
>>Address Withdraw) message MUST contain the addresses belonging to the
>>same address-family..
>> "
>> MA> This is yet another narrow interpretation of RFC 5036. There is no
>>justification for such a restriction and certainly RFC 5036 does not
>>make it. A FEC TLV contains list of FEC Elements which are opaque. Each
>>FEC Element has its own Type, Length, Value and is self sufficient.
>>Although implementations don't mix and match FEC elements but they are
>>designed to handle it. Same applies to Address list  TLV.
>> 
>> 
>> MA> I believe the need to handle duplicate interface addresses received
>>from two different peers is not a new issue. It needed to be handled in
>>existing IPv4 based LDP implementations. Maybe the authors can specify
>>why duplicate link local addresses is any different.
>> 
>> 
>> MA> GTSM must be optional as explained in RFC 5082. This draft is not
>>defining a new protocol and as such it should remain optional as in RFC
>>5036.
>> 
>>

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Mon, 6 Feb 2012 14:21:29 -0600

Hi Shane,
LDP as defined in RFC 5036 can carry multiple FEC types within an LDP session from a peer which is identified by the LDP identifier tuple {LSR-id, label-space-id}. If two LSR nodes using the same LSR-id want to advertise two different label spaces, then they must use two different Hello adjacencies and LDP sessions for that. Also, if an implementation supports virtualization of LDP, then a different LDP identifier altogether can be used to establish a separate LDP session. Other than that, there is no relation between the type of adjacency and the FEC which are carried. For example, the same LDP Hello Adjacency and LDP session are used to carry unicast FECs, multicast FECs (mLDP), and PW FECs between two directly connected peers.

As far as I know BGP is not very different. It offers the ability to carry IPv4 NLRI over a IPv6 session and vice versa.

If what is required is to carry IPv6 FECs on an IPv6 session and IPv4 on an IPv4 session between two LSRs,  then we should consider extending RFC 5036 to allow for two different LSR-id values sharing the same global label space. This way, we can have separate Hello adjacency and LDP session and it is up to the user to assign which FEC type is allowed on which LDP session. This is a new work item but in my view much cleaner and backward compatible with RFC 5036 than to try to tie the address family to the type of Hello adjacency. 

By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate Hello adjacency but a single shared LDP session. It is not exactly what you are asking for.

Regards,
Mustapha.

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Friday, February 03, 2012 11:32 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Mustapha,

Just my $0.02,

-shane

On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote:
> 5. Section 6.1 - Transport connection establishment "
> 6. Section 6.1 - Transport connection establishment "
> ======================================================================
> ================= _______________________________________________
> mpls mailing list
> [email-masked]

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 7 Feb 2012 02:00:08 +0530

I second to Mustapha. Further, we had already started LDP capabilities based approach on various FEC types support over a single LDP session (e.g 
mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a sound approach and would raise other questions such as which adjacency to be 
used for various mLdp fec types etc (as some of those has mix of ipv4 + ipv6) etc.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Monday, February 06, 2012 12:21 PM
To: Shane Amante
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Shane,

Regards,
Mustapha.

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Friday, February 03, 2012 11:32 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Mustapha,

Just my $0.02,

-shane

On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote:
> =================

---

From: Phil Bedard <[email-masked]>
Date: Mon, 06 Feb 2012 15:44:58 -0500

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

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

Phil 

On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"
<[email-masked]> wrote:

>I second to Mustapha. Further, we had already started LDP capabilities
>based approach on various FEC types support over a single LDP session
>(e.g 
>mLdp etc) so, separate hello adjacencies for IPV4 and IPV6 fecs is not a
>sound approach and would raise other questions such as which adjacency to
>be 
>LDP as defined in RFC 5036 can carry multiple FEC types within an LDP
>session from a peer which is identified by the LDP identifier tuple
>{LSR-id, label-space-id}. If two LSR nodes using the same LSR-id want to
>advertise two different label spaces, then they must use two different
>Hello adjacencies and LDP sessions for that. Also, if an implementation
>supports virtualization of LDP, then a different LDP identifier
>altogether can be used to establish a separate LDP session. Other than
>that, there is no relation between the type of adjacency and the FEC
>which are carried. For example, the same LDP Hello Adjacency and LDP
>session are used to carry unicast FECs, multicast FECs (mLDP), and PW
>FECs between two directly connected peers.
>
>As far as I know BGP is not very different. It offers the ability to
>carry IPv4 NLRI over a IPv6 session and vice versa.
>
>If what is required is to carry IPv6 FECs on an IPv6 session and IPv4 on
>an IPv4 session between two LSRs,  then we should consider extending RFC
>5036 to allow for two different LSR-id values sharing the same global
>label space. This way, we can have separate Hello adjacency and LDP
>session and it is up to the user to assign which FEC type is allowed on
>which LDP session. This is a new work item but in my view much cleaner
>and backward compatible with RFC 5036 than to try to tie the address
>family to the type of Hello adjacency.
>
>By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate Hello
>adjacency but a single shared LDP session. It is not exactly what you are
>asking for.
>
>Regards,
>Mustapha.
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 6 Feb 2012 13:12:08 -0800

Hi Phil,

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

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

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

Thanks,
Vishwas

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 7 Feb 2012 04:59:54 +0530

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

Thanks,
Pranjal

________________________________
From: Vishwas Manral [mailto:[email-masked]]
Sent: Monday, February 06, 2012 1:12 PM
To: Phil Bedard
Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante; [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Phil,

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

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

Thanks,
Vishwas
On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"
<[email-masked]<mailto:[email-masked]>> wrote:

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>Aissaoui, Mustapha (Mustapha)
>Cc: [email-masked]<mailto:[email-masked]>
>From: Shane Amante [mailto:[email-masked]<mailto:[email-masked]>]
>Cc: [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

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

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 6 Feb 2012 15:50:26 -0800

That's correct Pranjal.

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

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) <
[email-masked]> wrote:

>  That means in mobility backhauls if we are running 10K adjacencies
> today, this draft imposes us to run 20K adjacencies in case of IPV6. ****
>
> ** **
>
> Thanks,****
>
> Pranjal****
>
> ** **
>  ------------------------------
>
> *From:* Vishwas Manral [mailto:[email-masked]]
> *Sent:* Monday, February 06, 2012 1:12 PM
> *To:* Phil Bedard
> *Cc:* Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane
> Amante; [email-masked]
>
> *Subject:* Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> ****
>
>  ** **
>
> Hi Phil,
>
> You are right. If we want minimal fate-sharing, we could be using
> different instances of LDP itself or something in between, in which case we
> can use different LSR id/ MT extension etc.
>
> Vishwas****
> On Mon, Feb 6, 2012 at 12:44 PM, Phil Bedard <[email-masked]>
> wrote:****
>
> On 2/6/12 3:30 PM, "Dutta, Pranjal K (Pranjal)"****
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 7 Feb 2012 05:28:21 +0530

I would rather for complete separation with multiple lsr-id because having separate link adjacencies does not really solved any problem.
Since hello adjacencies are associated with a link, still fate sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
Having IPV4 and IPV6 specific hello adjacencies over a link would only decide whether such a link is to be programmed for IPV4 or IPV6 egress traffic but I see it as overkill and unnecessary scalability impacts.

Thanks,
Pranjal

________________________________
From: Vishwas Manral [mailto:[email-masked]]
Sent: Monday, February 06, 2012 3:50 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

That's correct Pranjal.

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

Thanks,
Vishwas
On Mon, Feb 6, 2012 at 3:29 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
That means in mobility backhauls if we are running 10K adjacencies today, this draft imposes us to run 20K adjacencies in case of IPV6.

Thanks,
Pranjal

________________________________
From: Vishwas Manral [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, February 06, 2012 1:12 PM
To: Phil Bedard
Cc: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Shane Amante; [email-masked]<mailto:[email-masked]>

Hi Phil,

Thanks,
Vishwas

Phil

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 6 Feb 2012 16:03:09 -0800

Good points Pranjal.

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

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) <
[email-masked]> wrote:

>  I would rather for complete separation with multiple lsr-id because
> having separate link adjacencies does not really solved any problem. ****
>
> Since hello adjacencies are associated with a link, still fate sharing
> would continue over the single ldp/tcp session for IPV4 and IPV6.****
>
> Having IPV4 and IPV6 specific hello adjacencies over a link would only
> decide whether such a link is to be programmed for IPV4 or IPV6 egress
> traffic but I see it as overkill and unnecessary scalability impacts.****
>
> ** **
>
> Thanks,****
>
> Pranjal****
>
> ** **
> *Sent:* Monday, February 06, 2012 3:50 PM
> *To:* Dutta, Pranjal K (Pranjal)
> *Cc:* Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante;
> [email-masked]
>
> [email-masked]> wrote:****
>
> That means in mobility backhauls if we are running 10K adjacencies today,
> this draft imposes us to run 20K adjacencies in case of IPV6. ****
>
>  ****
>
> Thanks,****
>
> Pranjal****
>
>  ****
> Amante; [email-masked]****
>
>
> *Subject:* Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06****
>
>  ****
>
> Hi Phil,
>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 07 Feb 2012 00:28:44 +0000

Is it something like that 3GPP takes one PDP for both IPv4 and IPv6? We take the similar approach?

Sent from my iPad

On Feb 6, 2012, at 4:03 PM, "Vishwas Manral" <[email-masked]<mailto:[email-masked]>> wrote:

Good points Pranjal.

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

Thanks,
Vishwas

On Mon, Feb 6, 2012 at 3:58 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
I would rather for complete separation with multiple lsr-id because having separate link adjacencies does not really solved any problem.
Since hello adjacencies are associated with a link, still fate sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
Having IPV4 and IPV6 specific hello adjacencies over a link would only decide whether such a link is to be programmed for IPV4 or IPV6 egress traffic but I see it as overkill and unnecessary scalability impacts.

Thanks,
Pranjal

Cc: Phil Bedard; Aissaoui, Mustapha (Mustapha); Shane Amante; [email-masked]<mailto:[email-masked]>

That's correct Pranjal.

Thanks,
Vishwas

Thanks,
Pranjal

Hi Phil,

Thanks,
Vishwas

Phil

---

From: Mark Tinka <[email-masked]>
Date: Sat, 11 Feb 2012 17:30:00 +0800

On Tuesday, February 07, 2012 04:44:58 AM Phil Bedard wrote:

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

As an operator, I have to agree with Phil as well.

Operators will expect that LDPv4 and LDPv6 will likely be 
different adjacencies, with independent FEC for each address 
family, even though the capabilities being advertised by LDP 
may be the same, but only activated based on whether those 
capabilities are in operation for that particular address 
family or not.

At any rate, fate sharing would be undesireable for 
operators. Moreover, I'd prefer that if operators have 
choice in how LDP would operate, independence of adjacencies 
and FEC's be the default, and a combination be optional.

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

This is very true.

In dual-stack systems, we (and a number of other operators) 
will have separate but similar deployments between IPv4 and 
IPv6 protocols. IS-IS is just about the only exception, but 
while the protocol integrates support for both IPv4 and 
IPv6, we still consider the operation of adjacencies 
separate on the wire.

Mark.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 17 Feb 2012 07:01:21 +0530

I think we are confusing separate ldp hello adjacencies with fate separation. I would be a bit more explicit. Having separate hello adjacencies for IPV4 and IPV6 but same ldp session DOES NOT yield fate separation. Fate separation would require two || ldp sessions between peers. What we raised is that - the separate hello adjacencies for ipv4 and ipv6 as per Ldp-ipv6 draft does not make any sense since we can do away with single 
adjacency with per adjacency capabilities. Fate separation is a different 
Problem which can be addressed by multi-lsr sessions between two peering 
Systems.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Tinka
Sent: Saturday, February 11, 2012 1:30 AM
To: [email-masked]
Cc: Aissaoui, Mustapha (Mustapha)
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

This is very true.

Mark.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 29 Feb 2012 21:27:56 -0600

Hi Mustapha, 

Thanks for the review of the document and the feedback. It is never too
late. :)
Sorry about the delay in getting back to you.

Please see inline,

> > below are comments on this draft. I realize this draft passed WG
last call but I
> think the issues are significant enough in my view. I apologize if
some of these
> comments were already raised on this mailing list.

Yes, they were discussed in the past and closed.

> loopback interface of the egress router, not any other interface. That
is why
> RFC 5036 explicitly states /32 for IPv4. In my view, we should
explicitly refer to
> /128 for IPv6.

No.

While it is a common practice to assign a host route to the loopback
interface, and it is a common practice to use loopback interface as the
next-hop, we must not assume the common practice to be the norm for the
protocol. In fact, there is NO technical argument against using the
non-host route on a loopback interface.

In fact, almost every implementation allows the next-hop to be a
non-host route, and I am aware of at least one implementation that
allows LDP to correctly resolve the next-hop when it uses a non-host
route.

> > Additionally, it is desirable that a packet is forwarded to an LSP
of an egress
> router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches
with that of
> the LDP hello adjacency on the next-hop interface.
> > "
should be
> removed.

RFC5036 actually does make a tie in section 2.5.5 in the sense that if
hello adj ceases to exist on an interface, then LDP concludes the lack
of MPLS forwarding on that interface. So, if IPv6 hello adj failed, then
stop the IPv6 MPLS forwarding (i.e. LSPv6) on that int, and vice versa,
instead of blindly stopping MPLS forwarding altogether. That wouldn't
make sense. 

//
   when it receives a Hello that matches the adjacency.  If the timer
   expires without receipt of a matching Hello from the peer, LDP
   concludes that the peer no longer wishes to label switch using that
   label space for that link (or target, in the case of Targeted Hellos)
   or that the peer has failed.  The LSR then deletes the Hello
 //

> > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has
anything
> to do with the address family. It only requires that an LSR advertises
the same
> transport address in all Hello adjacencies that advertise the same
label space.

I agree. It doesn't have anything to do with the address family, but it
becomes restrictive when having to accommodate transport of two
different address families (IPv4 and IPv6). Pls see more details on this
later on.

> In fact the intent as explained in the second sentence of that same
paragraph
> was to make sure that if two LSRs are establishing multiple Hello
adjacencies
> that they play the same active/passive role for establishing the TCP
connection.
> parallel links with different IPv4 transport addresses and it works
just fine. I
> think we should remove this restriction from RFC 5036 and not refer to
it in this
> draft.

That's not correct (and the implementation is in violation of RFC5036).

We had good discussion on this early on. In fact, we had an editor's
note on this in initial versions of this document to solicit discussion
on that.

The last para of section 2.5.2, as stated, would result in a particular
IP address (1.1.1.1, say) being encoded in the transport address in both
IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared
(which is what the WG agreed to during IETF 80), then it prohibits IPv6
hello from carrying IPv6 transport address (or IPv4 hello from carrying
IPv4 transport address). It would not make sense.

In other words, we wouldn't want IPv4 Hello to carry IPv6 transport
address and vice versa. It wouldn't make sense and would be incorrect.

That's why the change was needed.

> > MA> I understand the need to send both IPv4 and IPv6 Hello messages
over a
> dual-stack interface since there could be both IPv4 and IPv6 LSRs on
the same
> subnet. However, this does not justify the need to maintain two
separate Hello
> ajacencies per peer. In practice, each router can send both IPv4 and
IPv6 hellos
> but only a single Hello adjacency must be allowed with each peer
(LSR-id, label-
> space} over a given interface, whichever came up first. Over a P2P
interface, it
> is up to the user to configure which adjacency they want to form which
means
> there is only a need to send one type of hello.

We thought so too, but we uncovered various corner cases in which this
becomes problematic, not to mention that the indeterminism it would
bring into the picture. The easiest was to maintain hello adj per
address-family per peer.

For ex, consider three LDP enabled interfaces between R1 and R2, where
two are dual-stack, whereas the 3rd is single-stack (v4). If they
maintain only single adj, then they would have hello adj of one
transport (v6, say) on dual-stack interfaces, and another transport (v4,
say) on 3rd interface. 
	
Hello adj is tightly coupled with the functional LDP peering. If (the
last) hello adj is lost, then LDP peering must be brought down.
Additionally, if hello adj is gone from an interface, then LDP should
prohibit MPLS forwarding from using that interface.

Another way to think about it is - if IPv4 stops functioning on an
interface, but IPv6 keeps functioning, then IPv6 MPLS forwarding should
not be penalized. And vice versa.

Having separate hello adj maintenance is much cleaner/simpler and
provides deterministic behavior.

Nonetheless, an implementation could choose to optimize, if needed, to
keep both address-family related info in a single adjacency structure,
but this is all implementation specific. :)

> > MA> This is not a new issue. If I am not mistaken, this can also
occur in RFC
> 5036 implementations if an LSR receives two optional IPv4 transport
address
> TLVs. RFC 506 does not say what to do with this and was left for
> implementations to handle. If we absolutely need to specify something,
maybe
> we should say only the first TLV in the Hello message is processed.

Good point, but this is a different problem. It is not about the
sequence (which was ok if IPv4 hellow as carrying two IPv4 transport
addresses).

The problem is that allowing IPv4 based "discovery" to suggest an IPv6
transport address is fundamentally a wrong approach, IMO. How would IPv4
know that IPv6 transport is even functional (and vice versa).  IPv4
based discovery should suggest IPv4 transport, and IPv6 based discovery
should suggest IPv6 transport.

> maintained to each peer over a dual-stack interface.

We need the address-family awareness in peer hello adjacency/s, whether
it is a kept in a single adj structure or not.

Loosing the AFI awareness leads up the other problems that I mentioned
earlier. 

> > MA> I do not agree that the advertisement of IPv6 label-FEC bindings
should
> depend on the existence of an IPv6 Hello adjacency. This is a very
narrow
> interpretation of RFC 5036.
negotiate which
> FEC address family can be exchanged regardless if the Hello adjacency
is IPv4
> or IPv6. This is already done for multicast LDP (mLDP) FECs.

It is MAY. :)
It was changed to MAY based on the exhaustive discussion on mailing list
in 2011 for us to move forward. 

> containing FEC Elements of different address-family. In other words, a
FEC TLV
> in the label mapping message MUST contain the FEC Elements belonging
to the
> same address-family.
address-
> family. In other words, an Address List TLV in the Address (or Address
> Withdraw) message MUST contain the addresses belonging to the same
> address-family..
> > "
make it. A
> FEC TLV contains list of FEC Elements which are opaque. Each FEC
Element has
> its own Type, Length, Value and is self sufficient. Although
implementations
> don't mix and match FEC elements but they are designed to handle it.
Same
> applies to Address list  TLV.

We initially thought so too, until we discovered the following very
explicitly in RFC5036. This is a recipe for a disaster, if left
untreated. 

//
Section 3.5.5.1 -
If an LSR does not support the Address Family specified in the Address
List TLV, it SHOULD send an Unsupported Address Family Notification to
its LDP signaling an error and abort processing the message.

Section 3.4.1.1 -
If in decoding a FEC TLV an LSR encounters a FEC Element with an Address
Family it does not support, it SHOULD stop decoding the FEC TLV, abort
processing the message containing the TLV, and send an "Unsupported
Address Family" Notification message to its LDP peer signaling an error.
//

> > MA> I believe the need to handle duplicate interface addresses
received from
> two different peers is not a new issue. It needed to be handled in
existing IPv4
> based LDP implementations. Maybe the authors can specify why duplicate
link
> local addresses is any different.
 
Because it is native in IPv6 to allow for link-local addresses that IPv4
never allowed. 
So, what was an anomaly with IPv4 is now a standard behavior with IPv6,
hence, that verbiage.

> defining a new protocol and as such it should remain optional as in
RFC 5036.

We posed the Q about GTSM being the default or not during IETF 80, and
there were 10-yes and 0-no (mostly from operators)
Pls see the minutes, 
http://www.ietf.org/proceedings/80/minutes/mpls.txt

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Sent: Monday, February 06, 2012 3:21 PM
> To: Shane Amante
> Cc: [email-masked]
session
> from a peer which is identified by the LDP identifier tuple {LSR-id,
label-space-
> id}. If two LSR nodes using the same LSR-id want to advertise two
different label
> spaces, then they must use two different Hello adjacencies and LDP
sessions for
> that. Also, if an implementation supports virtualization of LDP, then
a different
> LDP identifier altogether can be used to establish a separate LDP
session. Other
> than that, there is no relation between the type of adjacency and the
FEC which
> are carried. For example, the same LDP Hello Adjacency and LDP session
are
> used to carry unicast FECs, multicast FECs (mLDP), and PW FECs between
two
> directly connected peers.
> 
carry IPv4 NLRI
> over a IPv6 session and vice versa.
> 
> If what is required is to carry IPv6 FECs on an IPv6 session and IPv4
on an IPv4
> session between two LSRs,  then we should consider extending RFC 5036
to
> allow for two different LSR-id values sharing the same global label
space. This
> way, we can have separate Hello adjacency and LDP session and it is up
to the
> user to assign which FEC type is allowed on which LDP session. This is
a new
> work item but in my view much cleaner and backward compatible with RFC
> 5036 than to try to tie the address family to the type of Hello
adjacency.
> adjacency but a single shared LDP session. It is not exactly what you
are asking
> for.
some of
> your comments.  Specifically, I get the sense from several of your
comments --
> actually, moreso from #3 -- that you are opposed to maintaining
separate LDP
> Hello and/or Session Adjacencies: 1 for each address family.  (If my
impression
> is incorrect I apologize).
> 
> I actually *do* want to have separate LDP Hello and Session
adjacencies: one
> per address family, at least at this point in time. I'm concerned
about
> [operational] issues that may develop in, for example, v6 affecting
the
> exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one
more
> concrete example, 6man/v6ops are only right now working on improving
the
> robustness of IPv6 ND to DoS attacks. There are potentially other
areas where
> IPv6 will be hardened, as well. The bottom-line is I do not want
problems in v6
> to affect exchange of FEC's + labels for v4, or vice-versa. Also,
FWIW, there has
> already been a precedent here wrt BGP where there it maintains
separate
> neighbors/sessions for each address family, so why aren't we doing the
same
> thing for LDP?
> 
> Ultimately, having separate sessions over-the-wire is much more
intuitive to
> operators in lots of cases where they may expect that a configuration
change
> or bugs they /think/ are only going to affect one address family,
really do only
> affect one address family. Besides, LDP Hello & Sessions timers, when
set to
> default, are extremely relaxed (order of several seconds), so the
burden on
> implementations to maintain separate sessions should be miniscule.
> 
> IMO, I would prefer that the default be separate Hellos & Sessions
over the
> wire to avoid "fate sharing". Only when an operator chooses to
explicitly
> configure their device to have hellos and sessions share fate should
the device
> do so.
> > below are comments on this draft. I realize this draft passed WG
last call but I
> think the issues are significant enough in my view. I apologize if
some of these
> comments were already raised on this mailing list.
> >
> > Regards,
> > Mustapha.
> >
is why
> RFC 5036 explicitly states /32 for IPv4. In my view, we should
explicitly refer to
> /128 for IPv6.
> > Additionally, it is desirable that a packet is forwarded to an LSP
of an egress
> router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches
with that of
> the LDP hello adjacency on the next-hop interface.
> > "
should be
> removed.
anything
> to do with the address family. It only requires that an LSR advertises
the same
> transport address in all Hello adjacencies that advertise the same
label space.
> In fact the intent as explained in the second sentence of that same
paragraph
> was to make sure that if two LSRs are establishing multiple Hello
adjacencies
> that they play the same active/passive role for establishing the TCP
connection.
> parallel links with different IPv4 transport addresses and it works
just fine. I
> think we should remove this restriction from RFC 5036 and not refer to
it in this
> draft.
over a
> dual-stack interface since there could be both IPv4 and IPv6 LSRs on
the same
> subnet. However, this does not justify the need to maintain two
separate Hello
> ajacencies per peer. In practice, each router can send both IPv4 and
IPv6 hellos
> but only a single Hello adjacency must be allowed with each peer
(LSR-id, label-
> space} over a given interface, whichever came up first. Over a P2P
interface, it
> is up to the user to configure which adjacency they want to form which
means
> there is only a need to send one type of hello.
> >
> >
> > MA> This is not a new issue. If I am not mistaken, this can also
occur in RFC
> 5036 implementations if an LSR receives two optional IPv4 transport
address
> TLVs. RFC 506 does not say what to do with this and was left for
> implementations to handle. If we absolutely need to specify something,
maybe
> we should say only the first TLV in the Hello message is processed.
> >
> >
should
> depend on the existence of an IPv6 Hello adjacency. This is a very
narrow
> interpretation of RFC 5036.
negotiate which
> FEC address family can be exchanged regardless if the Hello adjacency
is IPv4
> or IPv6. This is already done for multicast LDP (mLDP) FECs.
> >
> >
FEC TLV
> in the label mapping message MUST contain the FEC Elements belonging
to the
> same address-family.
address-
> family. In other words, an Address List TLV in the Address (or Address
> Withdraw) message MUST contain the addresses belonging to the same
> address-family..
> > "
make it. A
> FEC TLV contains list of FEC Elements which are opaque. Each FEC
Element has
> its own Type, Length, Value and is self sufficient. Although
implementations
> don't mix and match FEC elements but they are designed to handle it.
Same
> applies to Address list  TLV.
> >
> >
> > MA> I believe the need to handle duplicate interface addresses
received from
> two different peers is not a new issue. It needed to be handled in
existing IPv4
> based LDP implementations. Maybe the authors can specify why duplicate
link
> local addresses is any different.
> >
> >
> defining a new protocol and as such it should remain optional as in
RFC 5036.

---

From: Mark Tinka <[email-masked]>
Date: Thu, 1 Mar 2012 12:03:12 +0800

On Thursday, March 01, 2012 11:27:56 AM Rajiv Asati (rajiva) 
wrote:

> Nonetheless, an implementation could choose to optimize,
> if needed, to keep both address-family related info in a
> single adjacency structure, but this is all
> implementation specific. :)

I agree, and as mentioned earlier, as an operator, I'd 
rather this isn't the default. If a default needs to be 
implemented by a vendor, then AF separation would be my 
preference.

However, I'd support including knobs to allow operators to 
consolidate, if they so wished.

Mark.