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

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

On Feb 29, 2012, at 9:03 PM, Mark Tinka wrote:
> 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.

Well said, Mark. As an operator, as well, I concur with both points.

-shane

---

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

Hi Mark, Shane,

> > implemented by a vendor, then AF separation would be my

I agree with you. 

IPv4 and IPv6 info should be kept separate (my preference as well as I
alluded to it in my previous email), but we can't mandate the
implementation specifics in the RFC. Would you disagree? 

Cheers,
Rajiv

> -----Original Message-----
> From: Shane Amante [mailto:[email-masked]]
> Sent: Thursday, March 01, 2012 10:52 AM
> To: [email-masked]
> Cc: [email-masked]; Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha)
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> 
>

---

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

Hi Rajiv,
See some follow-up inline.

Regards,
Mustapha.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Wednesday, February 29, 2012 10:28 PM
To: Aissaoui, Mustapha (Mustapha); Shane Amante
Cc: [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

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.

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

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.

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

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> Not really. The "matching" has nothing to do with the type of FEC. It has to do with the parameters of the adjacency (LSRid, label space) over that link.

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

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

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> When parallel links exist between two LSRs, the TCP connection is bootstrapped by one of the hello adjacencies. An implementation compliant to RFC 5036 will not accept two TCP connections between the same two LSRs and thus the fact that the transport addresses exchanged are different has no impact. In fact take the simple case of a link LDP and a T-LDP sessions for directly connected LSRs. The T-LDP can use a loopback address as the transport address while the link LDP can use the link address as the transport address and they will both share the same TCP connection which was bootstrapped first. It becomes an issue of association of multiple Hello adjacencies with a single TCP connection. That is why I am saying the last paragraph of section 2.5.2 should be removed from RFC 5036.

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

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> The proper way to handle this is to implement separate LDP sessions not separate Hello adjacencies sharing the same LDP session. Current standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be exchanges and they do not require separate hello adjacencies. These are just FEC types and have no relationship whatsoever to the type of adjacency.

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

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.

MA> Again, what you are asking for can be solved with the use of separate LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 connection and vice-versa. There is no relationship whatsoever between the type of TCP conneciton in BGP and the NRLI family exchanged.

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

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.

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

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

MA> Bottom line, you are changing the behaviour of RFC 5036. This is a different protocol.

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

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> Well all this is controlled via the LDP capability or configuring the FEC filters. If after this, the node still receives the unsupported FEC or address type, what else do you suggest it should do?

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

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.

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

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

MA> Well that certainly contradicts the process. If you are creating a new LDP version protocol, we can consider making it mandatory by default. If you claim you are still compliant to RFC 5036 then you cannot change it and it must remain optional.

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Monday, February 06, 2012 3:21 PM
> To: Shane Amante
> Cc: [email-masked]
> 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.
> Sent: Friday, February 03, 2012 11:32 PM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: [email-masked]
> 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.
> >
> >
> ================================================================
> ======
> > =================
> _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

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

On Friday, March 02, 2012 11:47:39 AM Rajiv Asati (rajiva) 
wrote:

> IPv4 and IPv6 info should be kept separate (my preference
> as well as I alluded to it in my previous email), but we
> can't mandate the implementation specifics in the RFC.
> Would you disagree?

I'm okay not to necessarily define the detailed specifics 
inside the RFC, provided we don't sacrifice inter-vendor 
operability.

For specifics, vendors can detail their implementations in 
their manuals for operators to feed on, but only as long as 
operators can inter-operate a particular method (integrated 
or separate AF's) without issue.

Mark.

---

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

Mark,

Indeed. We are in agreement on this.
Thanks for your feedback.

Cheers,
Rajiv

> From: Mark Tinka [mailto:[email-masked]]
> Sent: Friday, March 02, 2012 1:35 AM
> To: Rajiv Asati (rajiva)
> Cc: Shane Amante; [email-masked]; Aissaoui, Mustapha (Mustapha)

---

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

Hi Mustapha,

Thanks for the discussion. Please see inline,
	
1. 
Given the lack of response for #1, I am assuming this we have agreed and
closed the discussion on this point. Thanks.

2. 
> MA> Not really. The "matching" has nothing to do with the type of FEC.
It has
> to do with the parameters of the adjacency (LSRid, label space) over
that link.

It is not about the FEC. It is about the LSP, and rightfully so. 

Hopefully, answering this Q will help us - If there are 3 links (LDP
enabled) between two LSRs and only two have hello adj leading to the
working LDP session, then would the LSRs use the 3rd link (which doesn't
have valid hello adj) for MPLS packet forwarding?

- If your answer is Yes, then we have a fundamental disagreement
independent of LDP IPv6.
- If the answer is No, then that's inline with what's described in the
last para of section 3 - differentiating IPv4 hello adj from IPv6 hello
adj. 
	Perhaps, the text needs a bit of rephrasing, so please feel free
to suggest.

The above has no bearing on FEC type e.g. IPv4 packet being sent over
LSPv6 or vice versa. 

Hence, we leave the text as-it-is.

3. 

> adjacencies with a single TCP connection. That is why I am saying the
last
> paragraph of section 2.5.2 should be removed from RFC 5036.

Removing last paragraph of section 2.5.2 from RFC 5036 ? 

That would fundamentally break RFC5036.

> MA> When parallel links exist between two LSRs, the TCP connection is
> bootstrapped by one of the hello adjacencies. An implementation
compliant
> to RFC 5036 will not accept two TCP connections between the same two
LSRs
> and thus the fact that the transport addresses exchanged are different
has
> no impact. In fact take the simple case of a link LDP and a T-LDP
sessions for
> directly connected LSRs. The T-LDP can use a loopback address as the
> transport address while the link LDP can use the link address as the
transport
> address and they will both share the same TCP connection which was
> bootstrapped first. 

Correct and that's because each LSR uses the same LDP Identifier and
qualifies for the point 1 of section 2.5.2 in RFC5036, which suggests to
not establish a new session if there is already one existing using the
same LDP Identifier: 

//
      1. If LSR1 does not already have an LDP session for the exchange
         of label spaces LSR1:a and LSR2:b, it attempts to open a TCP
//

> It becomes an issue of association of multiple Hello
> adjacencies with a single TCP connection. 

And it is not an issue thanks to the last para of section 2.5.2. We can
NOT afford to remove it.

Hence, we leave the text as-it-is in section 4 of ldp-ipv6.

4.
> MA> The proper way to handle this is to implement separate LDP
sessions
> not separate Hello adjacencies sharing the same LDP session. Current
> standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be
> exchanges and they do not require separate hello adjacencies. These
are just
> FEC types and have no relationship whatsoever to the type of
adjacency.

That's incorrect. As you know, PW-FEC, as per RFC5036, already requires
'extended/targetted hello adj', not 'basic hello adj' with the peer
before exchanging PW-FECs with that peer.

In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is
enabled on an interface. This is already implicit in RFC5036.
And if the interface is a dual-stack interface, then the behavior
shouldn't change. 

5. 
> MA> Again, what you are asking for can be solved with the use of
separate
> LDP sessions for IPv4 and IPv6. This is a deployment choice and not a
protocol
> design decision. 

Well, RFC5036 (LDP version 1) prescribes using a single session for
exchanging FEC-label bindings for various FEC types.

We could work on version 2 to move away from that intention e.g. allow
using more than one session between two LSRs. 

> BGP allows the exchage of IPv4 prefixes over an IPv6
> connection and vice-versa. There is no relationship whatsoever between
the
> type of TCP conneciton in BGP and the NRLI family exchanged.

Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying.
Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be
exchanged, as permitted.
We are in agreement here.

6.
Given the lack of response for #6, I am assuming this we have agreed and
closed the discussion on this point. Thanks.

7.

> MA> Bottom line, you are changing the behaviour of RFC 5036. This is a

Please see my response to #4.  Nonetheless, this is moot, as it is a
MAY, and is local to the LSR.
FWIW, this point has been beaten to death last yr, and I would urge you
to check the discussion on the mailing list from last yr.

8.

> MA> Well all this is controlled via the LDP capability or configuring
the FEC
> filters. If after this, the node still receives the unsupported FEC or
address
> type, what else do you suggest it should do?

If the node still receives the unsupported FEC or address type, then it
indicates that the peer has a bug, and it should follow the behavior
specified in RFC5036 e.g. declare a fatal error.

This is orthogonal to capability or FEC filter, since the assumption
here is that an LSR is willing to send/receive FEC-label bindings for
both IPv4 and IPv6 and more. The point is that the loophole that has
existed all along is closed when an LSR gets upgraded with the code
compliant with this specification. 

9.
Given the lack of response for #1, I am assuming this we have agreed and
closed the discussion on this point. Thanks.

10.

> MA> Well that certainly contradicts the process. If you are creating a
new LDP
> version protocol, we can consider making it mandatory by default. If
you
> claim you are still compliant to RFC 5036 then you cannot change it
and it
> must remain optional.

You do make a good point about us not changing the LDP protocol version,
so, it is not a new protocol, and I agree. 
I will consider to change GTSM to optional (MAY), subjected to Carlos's
opinion.

We will revisit it if/when the consensus suggests otherwise prior to RFC
publication.
We can close this point as well.

Cheers,
Rajiv

> From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-
> lucent.com]
> Sent: Friday, March 02, 2012 1:09 AM
> To: Rajiv Asati (rajiva)
> Cc: [email-masked]
> 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,
> 
> 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.
> 
> 
> 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.
> 
> //
> MA> Not really. The "matching" has nothing to do with the type of FEC.
It has
> to do with the parameters of the adjacency (LSRid, label space) over
that link.
> 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.
> 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
> 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.
> 
> MA> When parallel links exist between two LSRs, the TCP connection is
> bootstrapped by one of the hello adjacencies. An implementation
compliant
> to RFC 5036 will not accept two TCP connections between the same two
LSRs
> and thus the fact that the transport addresses exchanged are different
has
> no impact. In fact take the simple case of a link LDP and a T-LDP
sessions for
> directly connected LSRs. The T-LDP can use a loopback address as the
> transport address while the link LDP can use the link address as the
transport
> address and they will both share the same TCP connection which was
> bootstrapped first. It becomes an issue of association of multiple
Hello
> adjacencies with a single TCP connection. That is why I am saying the
last
> paragraph of section 2.5.2 should be removed from RFC 5036.
> 
> 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.
> 
> 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> The proper way to handle this is to implement separate LDP
sessions
> not separate Hello adjacencies sharing the same LDP session. Current
> standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be
> exchanges and they do not require separate hello adjacencies. These
are just
> FEC types and have no relationship whatsoever to the type of
adjacency.
> 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.
> 
> MA> Again, what you are asking for can be solved with the use of
separate
> LDP sessions for IPv4 and IPv6. This is a deployment choice and not a
protocol
> design decision. BGP allows the exchage of IPv4 prefixes over an IPv6
> connection and vice-versa. There is no relationship whatsoever between
the
> type of TCP conneciton in BGP and the NRLI family exchanged.
> 
> We need the address-family awareness in peer hello adjacency/s,
whether it
> is a kept in a single adj structure or not.
> 
> It was changed to MAY based on the exhaustive discussion on mailing
list in
> 2011 for us to move forward.
> 
> 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> Well all this is controlled via the LDP capability or configuring
the FEC
> filters. If after this, the node still receives the unsupported FEC or
address
> type, what else do you suggest it should do?
> 
> 
> 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.
> 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
> 
> MA> Well that certainly contradicts the process. If you are creating a
new LDP
> version protocol, we can consider making it mandatory by default. If
you
> claim you are still compliant to RFC 5036 then you cannot change it
and it
> must remain optional.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 28 Mar 2012 14:56:24 -0500

Hi Rajiv,
I am afraid we are not making progress on the technical questions I raised on this draft.

For the benefit of everyone else on the mailing list, I am going to state the main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. This proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) which can be resolved in the datapath over a given link based on the type of the control plane adjacency (IPv4 or IPv6) established over that link. This coupling of FEC resolution to the type of control plane adjacency is not correct and breaks so many things in RFC 5036. In RFC 5036, the ability to resolve a FEC type between peers is independent of the adjacency established.

In addition, this proposal now means that we need 2 link Hello adjacencies over each link and 2 targeted Hello adjacencies between any two LSR nodes. This is not good from a scaling perspective while it provides no gain.

In an earlier exchange on this thread, we discussed the need for introducing per Hello adjacency capability negotiation to address the probem of which FEC types can be resolved over a given link adjacency. That is the correct approach to the problem and we should keep the behaviour of RFC 5036 as is, that is an IPv4 link Hello adjacency will bootstrap an IPv4 LDP session and an IPv6 link adjacency will bootstrap an IPv6 LDP session. There is no need or value for two link Hellos associating with the same IPv4 or IPv6 LDP session.

Regards,
Mustapha.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Monday, March 12, 2012 12:25 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: [email-masked]; Carlos Pignataro (cpignata)
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Mustapha,

1.
Given the lack of response for #1, I am assuming this we have agreed and closed the discussion on this point. Thanks.

2.
It has
that link.

Hopefully, answering this Q will help us - If there are 3 links (LDP
enabled) between two LSRs and only two have hello adj leading to the working LDP session, then would the LSRs use the 3rd link (which doesn't have valid hello adj) for MPLS packet forwarding?

- If your answer is Yes, then we have a fundamental disagreement independent of LDP IPv6.
- If the answer is No, then that's inline with what's described in the last para of section 3 - differentiating IPv4 hello adj from IPv6 hello adj.
        Perhaps, the text needs a bit of rephrasing, so please feel free to suggest.

3.

last

compliant
LSRs
has
sessions for
transport
> address and they will both share the same TCP connection which was

Correct and that's because each LSR uses the same LDP Identifier and qualifies for the point 1 of section 2.5.2 in RFC5036, which suggests to not establish a new session if there is already one existing using the same LDP Identifier:

//
      1. If LSR1 does not already have an LDP session for the exchange
         of label spaces LSR1:a and LSR2:b, it attempts to open a TCP //

> It becomes an issue of association of multiple Hello adjacencies with
> a single TCP connection.

And it is not an issue thanks to the last para of section 2.5.2. We can NOT afford to remove it.

4.
sessions
are just
adjacency.

That's incorrect. As you know, PW-FEC, as per RFC5036, already requires 'extended/targetted hello adj', not 'basic hello adj' with the peer before exchanging PW-FECs with that peer.

In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is enabled on an interface. This is already implicit in RFC5036.
And if the interface is a dual-stack interface, then the behavior shouldn't change.

5.
separate
protocol
> design decision.

Well, RFC5036 (LDP version 1) prescribes using a single session for exchanging FEC-label bindings for various FEC types.

We could work on version 2 to move away from that intention e.g. allow using more than one session between two LSRs.

> BGP allows the exchage of IPv4 prefixes over an IPv6 connection and
> vice-versa. There is no relationship whatsoever between
the

Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying.
Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be exchanged, as permitted.
We are in agreement here.

6.
Given the lack of response for #6, I am assuming this we have agreed and closed the discussion on this point. Thanks.

7.

> MA> Bottom line, you are changing the behaviour of RFC 5036. This is a

Please see my response to #4.  Nonetheless, this is moot, as it is a MAY, and is local to the LSR.
FWIW, this point has been beaten to death last yr, and I would urge you to check the discussion on the mailing list from last yr.

8.

the FEC
address
> type, what else do you suggest it should do?

If the node still receives the unsupported FEC or address type, then it indicates that the peer has a bug, and it should follow the behavior specified in RFC5036 e.g. declare a fatal error.

This is orthogonal to capability or FEC filter, since the assumption here is that an LSR is willing to send/receive FEC-label bindings for both IPv4 and IPv6 and more. The point is that the loophole that has existed all along is closed when an LSR gets upgraded with the code compliant with this specification.

9.
Given the lack of response for #1, I am assuming this we have agreed and closed the discussion on this point. Thanks.

10.

new LDP
you
and it
> must remain optional.

You do make a good point about us not changing the LDP protocol version, so, it is not a new protocol, and I agree.
I will consider to change GTSM to optional (MAY), subjected to Carlos's opinion.

We will revisit it if/when the consensus suggests otherwise prior to RFC publication.
We can close this point as well.

Cheers,
Rajiv

too late.
interface,
we
In
on a
non-host
to
hello adj
the IPv6
blindly
It has
that link.
it
different
on.
note on
that.
particular IP address
(which is
from
address
compliant
LSRs
has
sessions for
transport
Hello
last
bring
address-family per
maintain only
on dual-
prohibit
interface, but
penalized.
provides
but this
sessions
are just
adjacency.
sequence
addresses).
IPv4
based
should
separate
protocol
the
whether it
list in
> different protocol.
explicitly in
List
LDP
Address
error.
the FEC
address
IPv4 never
IPv6,
minutes,
new LDP
you
and it

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 28 Mar 2012 16:05:34 -0400

I second the same concern and fail to understand the rationale to bypass the available
tool (capacity negotiation).
Thanks,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Wednesday, March 28, 2012 3:56 PM
To: Rajiv Asati (rajiva)
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Rajiv,

Regards,
Mustapha.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Monday, March 12, 2012 12:25 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: [email-masked]; Carlos Pignataro (cpignata)
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Mustapha,

1.

2.
It has
that link.

3.

last

compliant
LSRs
has
sessions for
transport

//

4.
sessions
are just
adjacency.

5.
separate
protocol

the

6.

7.

8.

the FEC
address

9.

10.

new LDP
you
and it

Cheers,
Rajiv

too late.
interface,
we
In
on a
non-host
to
hello adj
the IPv6
blindly
It has
that link.
it
different
on.
note on
that.
particular IP address
(which is
from
address
compliant
LSRs
has
sessions for
transport
Hello
last
bring
address-family per
maintain only
on dual-
prohibit
interface, but
penalized.
provides
but this
sessions
are just
adjacency.
sequence
addresses).
IPv4
based
should
separate
protocol
the
whether it
list in
explicitly in
List
LDP
Address
error.
the FEC
address
IPv4 never
IPv6,
minutes,
new LDP
you
and it

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 29 Mar 2012 02:31:20 +0530

I have raised the same in mailing list multiple times, but no **technical justification** has been provided in answers. Apart from scaling implications, LDP FEC next-hop resolution algorithms does not have dependency with what is the IP address type  being used for LDP hello adjacency.

If ldp-ipv6 authors claim that IPv6 FEC resolution is different than how we have been doing so far and ipv6 based hello adjacency is a MUST in order for existing LDP implementations to resolve next-hop for an IPV6 FEC then that requires a technical debate in this mailing list.

Yes, we are certainly not making any progress on the technical questions we had raised.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Wednesday, March 28, 2012 12:56 PM
To: Rajiv Asati (rajiva)
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Rajiv,

Regards,
Mustapha.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Monday, March 12, 2012 12:25 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: [email-masked]; Carlos Pignataro (cpignata)
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Mustapha,

1.

2.
It has
that link.

3.

last

compliant
LSRs
has
sessions for
transport

//

4.
sessions
are just
adjacency.

5.
separate
protocol

the

6.

7.

8.

the FEC
address

9.

10.

new LDP
you
and it

Cheers,
Rajiv

too late.
interface,
we
In
on a
non-host
to
hello adj
the IPv6
blindly
It has
that link.
it
different
on.
note on
that.
particular IP address
(which is
from
address
compliant
LSRs
has
sessions for
transport
Hello
last
bring
address-family per
maintain only
on dual-
prohibit
interface, but
penalized.
provides
but this
sessions
are just
adjacency.
sequence
addresses).
IPv4
based
should
separate
protocol
the
whether it
list in
explicitly in
List
LDP
Address
error.
the FEC
address
IPv4 never
IPv6,
minutes,
new LDP
you
and it