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

From: Eric Gray <[email-masked]>
Date: Fri, 10 Feb 2012 14:23:57 -0500

Forwarded in plain text...

________________________________

From: Vishwas Manral [mailto:[email-masked]]
Sent: Monday, February 06, 2012 11:03 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Kishore Tiruveedhula; Aissaoui, Mustapha (Mustapha); [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Pranjal,

They would definitely share fate if we used one session.

However if we used just one adjacency, we would loose a functionality of Hello's that of verifying peer connectivity. Do you think it is not critical in such a case?

Thanks,
Vishwas

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

        Yes, that's what I suggested. However it won't solve the concerns raised by Shane and Phil since IPV4 + IPV4 tunnels would fate share over single ldp session. The solution to that can be separation of lsr-ids for IPV4 and IPV6 sessions between same peers.

        Thanks,

        Pranjal

        ________________________________

                From: Kishore Tiruveedhula [mailto:[email-masked]]
        Sent: Monday, February 06, 2012 6:29 PM
        To: Vishwas Manral; Dutta, Pranjal K (Pranjal)

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

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

        How about defining new IPv6 capability Parameter TLV, which can be sent in the Init message, instead of maintaining two separate Ipv4 and Ipv6 adjacencies for single link?

        Thanks,

        Kishore

        From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
        Sent: Monday, February 06, 2012 7:03 PM
        To: Dutta, Pranjal K (Pranjal)
        Cc: Aissaoui, Mustapha (Mustapha); [email-masked]
        Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

        Good points Pranjal.

        The idea is simple, the current specs allow multiple adjacencies and still have a single session. We are allowing IPv4 and IPv6 adjacencies to check 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

        ________________________________

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

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

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

        Thanks,
        Vishwas

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

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

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

        Phil

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

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

---

From: Eric Gray <[email-masked]>
Date: Fri, 10 Feb 2012 14:23:59 -0500

From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]]
Sent: Monday, February 06, 2012 8:28 PM
To: Aissaoui, Mustapha (Mustapha); [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Yes, LDP hello adjacency has no relation ship with fec types advertised - that's an exclusive capability of the ldp session only.

Multiple link hello adjacency defines ECMP programming behaviour only. On theory/paper there may not be a difference

between 10K and 20K hello adjacencies but in reality it matters a lot on implementations. I don't see any strong technical reason

for separate hello adjacencies for IPv4 and IPV6, rather go for separate || LDP sessions between two peers for better fec

type demux behaviour/alleviate shared-fate concerns etc.

Thanks,

Pranjal

From: Aissaoui, Mustapha (Mustapha)
Sent: Monday, February 06, 2012 5:09 PM
To: [email-masked]'; Dutta, Pranjal K (Pranjal)
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

There is actually a fundamental difference between the parallel links in RFC 5036 and this proposal. The tie introduced between any of the Hello adjacencies and the FEC type advertised. In LDP so far this is controlled by per-peer prefix policies and LDP capability.

If the intent is to provide some level of control plane separation, as explained by Shane and Phil, then we would need separate Hello adjacencies and separate LDP sessions and let users decide what FEC types they want to use for each. There is no point of creating a hybrid scheme which doubles the number of adjacencies and changes the LDP state machine for no apparent gain.

Mustapha.
Sent from my Blackberry!

From: Vishwas Manral <[email-masked]>
To: Dutta, Pranjal K (Pranjal)
Cc: Phil Bedard <[email-masked]>; Aissaoui, Mustapha (Mustapha); Shane Amante <[email-masked]>; [email-masked] <[email-masked]>
Sent: Mon Feb 06 18:03:09 2012
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Good points Pranjal.

Thanks,
Vishwas

Thanks,

Pranjal

That's correct Pranjal.

Thanks,
Vishwas

Thanks,

Pranjal

Hi Phil,

Thanks,
Vishwas

Phil

---

From: Eric Gray <[email-masked]>
Date: Fri, 10 Feb 2012 14:23:58 -0500

Sent: Monday, February 06, 2012 9:29 PM

Thanks,

Kishore

Good points Pranjal.

Thanks,
Vishwas

Thanks,

Pranjal

That's correct Pranjal.

Thanks,
Vishwas

Thanks,

Pranjal

Hi Phil,

Thanks,
Vishwas

Phil

---

From: Eric Gray <[email-masked]>
Date: Fri, 10 Feb 2012 14:23:58 -0500

From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]]
Sent: Monday, February 06, 2012 9:51 PM
To: Kishore Tiruveedhula; Vishwas Manral
Cc: Aissaoui, Mustapha (Mustapha); [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Thanks,

Pranjal

Thanks,

Kishore

Good points Pranjal.

Thanks,
Vishwas

Thanks,

Pranjal

That's correct Pranjal.

Thanks,
Vishwas

Thanks,

Pranjal

Hi Phil,

Thanks,
Vishwas

Phil

---

From: Eric Gray <[email-masked]>
Date: Fri, 10 Feb 2012 14:23:56 -0500

From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]]
Sent: Tuesday, February 07, 2012 1:49 PM
To: Vishwas Manral
Cc: Kishore Tiruveedhula; Aissaoui, Mustapha (Mustapha); [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Viswas,

                 If we use multiple lsr-ids then there would be two separate hello adjacencies anyway over a single interface so that situation  won't arise. It would still be 20K adj + sessions if we want fate separation of ipv4 and ipv6 but is much cleaner then having multiple

adjacencies on a link with same peer lsr.

Thanks,

Pranjal

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

Hi Pranjal,

Thanks,
Vishwas

Thanks,

Pranjal

Thanks,

Kishore

Good points Pranjal.

Thanks,
Vishwas

Thanks,

Pranjal

That's correct Pranjal.

Thanks,
Vishwas

Thanks,

Pranjal

Hi Phil,

Thanks,
Vishwas

Phil

---

From: Eric Gray <[email-masked]>
Date: Fri, 10 Feb 2012 14:24:00 -0500

From: Aissaoui, Mustapha (Mustapha) [mailto:[email-masked]]
Sent: Monday, February 06, 2012 8:09 PM
To: [email-masked]'; Dutta, Pranjal K (Pranjal)
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Mustapha.
Sent from my Blackberry!

Good points Pranjal.

Thanks,
Vishwas

        Thanks,

        Pranjal

        That's correct Pranjal.

        Thanks,
        Vishwas

        Thanks,

        Pranjal

        Hi Phil,

        Thanks,
        Vishwas

        Phil