Subject: Re: [mpls] Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06)

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 1 Apr 2012 05:20:15 -0500

Hi Himanshu, 

Appreciate your question. There are at least two benefits for sending
IPv6 hello & IPv4 hello and maintaining hello adj for both on a
dual-stack interface if enabled with both LDP IPv4 and LDP IPv6:
		
1. Discovering v4 or/and v6 transport that the peer is willing to use
for bootstrapping the subsequent TCP session (and resorting to using the
alternate transport if the preferred one failed)
	Similar to that of happy eyeball (unless hardcoded or got into
collision)! 

2. Resolving the label correctly even if duplicate IPv6 LLAs are used as
the routing next-hops
	Please see section 8 for more details
	http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-06#section-8

While it may be tempting to maintain only one hello adj (IPv4, say)
(that got used to establish the subsequent (IPv4, say) TCP/LDP session)
and let go of the other hello adj (IPv6, say) that didn't get used, it
could cause traffic blackholing (due to missing #2 above) for packets
going on LSPv6.

Does this clarify?

Cheers,
Rajiv

> -----Original Message-----
> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2012 4:06 PM
> To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva)
> Cc: [email-masked]
> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> 
> 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,
> 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,
> 
> 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
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> >
> > 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
> >
> >
> > > -----Original Message-----
> > > 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]
> > > 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.
> > > >
> > > >
> > >
> > ==========================================================
> > ======
> > > ======
> > > > =================
> > > _______________________________________________
> > > > mpls mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls
> > >
> > > _______________________________________________
> > > 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: "Shah, Himanshu" <[email-masked]>
Date: Sun, 1 Apr 2012 07:59:30 -0400

Thanks Rajiv. It does clarify for me.
Can you also clarify that this is limited to link hello and
not applicable to targeted hello, especially the LDP adjacencies/sessions
we use for PW signaling (as they tend to have +many+ LDP peers!!)

rgds,
Himanshu

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Sunday, April 01, 2012 6:20 AM
To: Shah, Himanshu
Cc: [email-masked]; Aissaoui, Mustapha (Mustapha)
Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06)

Hi Himanshu,

Does this clarify?

Cheers,
Rajiv

bypass the
Of
raised on
state the
This
which can be
control
coupling of FEC
breaks so
type between
adjacencies over
This is
introducing
which FEC
approach
that is an
IPv6 link
value for two
and
FEC.
working
valid
independent
last para of
free to suggest.
the
is
different
qualifies
establish a
//
with
can NOT afford
requires
before
is
shouldn't
a
exchanging
using
and
a
MAY, and is
you to
configuring
or
it indicates
in RFC5036
here is that
IPv6 and
closed when an
and
a
version, so, it
Carlos's opinion.
RFC
referring
next-hop,
route
LSP
if
stop
timer
that
FEC.
MUST
the
same
TCP
works
refer
is
different
the
on
and
this
where
say)
(the
should
to
structure,
IPv4
transport
processed.
IPv6
a
IPv6
between
new
IPv6
dual-
IPv6
RFC5036.
new
mentioned
(as
a
that
words,
belonging
not
it.
Address
its
abort
configuring
or
connection
LDP
is
in
and
a
Behalf
{LSR-id,
to
label
is
This
input
my
affecting
improving
should
referring
LSP
MUST
the
same
TCP
works
refer
on
and
IPv4
transport
processed.
new
IPv6
dual-
IPv6
RFC5036.
new
(as
that
words,
belonging
not
it.
connection
LDP
is
in

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 1 Apr 2012 12:37:04 -0500

Hi Himanshu,

Glad that we are in sync.

You are right that neither of those two points apply to targeted
hello/discovery (since peer IP address is known apriori).

Cheers,
Rajiv

> Sent: Sunday, April 01, 2012 8:00 AM
> To: Rajiv Asati (rajiva)
> Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on
draft-ietf-
> mpls-ldp-ipv6-06)
> Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on
draft-ietf-
> mpls-ldp-ipv6-06)

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Mon, 2 Apr 2012 22:20:15 -0500

Hi Rajiv,
Could you provide in details how you believe the presence of duplicate link-local addresses from two neighbouring LSRs can cause blackhole of traffic?

What you describe in Section 8 is already how implementations of RFC 5036 operate. Before you can resolve a FEC to a link, you have to find out the outgoing interface and next-hop of that FEC prefix in the routing table. Then you need to find the LSR-id which advertised that next-hop address as its local address and that there is a hello adjacency to that LSR-id over that interface. In the case of a dual-stack inteface, you just need to find a link Hello adjacency over that interface, it does not have to be an IPv6 adjacency, to resolve an IPv6 FEC.

Because LDP follows routing, you cannot blackhole traffic when overalpping link-local addresses exist to different LDP peers over two different interfaces or subnets. If overlapping occurs over the same subnet, then neighbour discovery will detect it and will shutdown IPv6 forwarding over that interface.

Again, there is no relationship of FEC resolution to a link and the type of the control plane adjacency. You just need to have an adjacency.

Regards,
Mustapha.

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Sunday, April 01, 2012 6:20 AM
To: Shah, Himanshu
Cc: [email-masked]; Aissaoui, Mustapha (Mustapha)
Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06)

Hi Himanshu,

Appreciate your question. There are at least two benefits for sending
IPv6 hello & IPv4 hello and maintaining hello adj for both on a dual-stack interface if enabled with both LDP IPv4 and LDP IPv6:

1. Discovering v4 or/and v6 transport that the peer is willing to use for bootstrapping the subsequent TCP session (and resorting to using the alternate transport if the preferred one failed)
        Similar to that of happy eyeball (unless hardcoded or got into collision)!

2. Resolving the label correctly even if duplicate IPv6 LLAs are used as the routing next-hops
        Please see section 8 for more details
        http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-06#section-8

While it may be tempting to maintain only one hello adj (IPv4, say) (that got used to establish the subsequent (IPv4, say) TCP/LDP session) and let go of the other hello adj (IPv6, say) that didn't get used, it could cause traffic blackholing (due to missing #2 above) for packets going on LSPv6.

Does this clarify?

Cheers,
Rajiv

bypass the
Of
raised on
state the
This
which can be
control
coupling of FEC
breaks so
type between
adjacencies over
This is
introducing
which FEC
approach
that is an
IPv6 link
value for two
and
FEC.
working
valid
independent
last para of
free to suggest.
the
is
different
qualifies
establish a
//
with
can NOT afford
requires
before
is
shouldn't
a
exchanging
using
and
a
MAY, and is
you to
configuring
or
it indicates
in RFC5036
here is that
IPv6 and
closed when an
and
a
version, so, it
Carlos's opinion.
RFC
referring
next-hop,
route
LSP
if
stop
timer
that
FEC.
MUST
the
same
TCP
works
refer
is
different
the
on
and
this
where
say)
(the
should
to
structure,
IPv4
transport
processed.
IPv6
a
IPv6
between
new
IPv6
dual-
IPv6
RFC5036.
new
mentioned
(as
a
that
words,
belonging
not
it.
Address
its
abort
configuring
or
> > > > 10. Section 9 - LDP TTL Security "
connection
LDP
is
in
and
a
Behalf
{LSR-id,
to
label
is
This
input
my
affecting
improving
should
referring
LSP
MUST
the
same
TCP
works
refer
on
and
IPv4
transport
processed.
new
IPv6
dual-
IPv6
RFC5036.
new
(as
that
words,
belonging
not
it.
> > > > 10. Section 9 - LDP TTL Security "
connection
LDP
is
in

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 5 Apr 2012 14:45:42 -0500

Hi Mustapha,

Please see inline,

> Could you provide in details how you believe the presence of duplicate
link-
> local addresses from two neighbouring LSRs can cause blackhole of
traffic?

R1--R2----R3---R4----"x"
        \-----R5-----------"y"

R2 has a path via R3 to "x". Say, routing next-hop = LLAx.
R3 and R5 use the same LLA (=LLAx) towards R2.  

Relying on just RFC5036 section 2.7 that describes the next-hop/label
resolution using ADDRESS message and says nothing about Hello Adjacency,
R2 may map LLAx to R5 and use R5's label while forwarding to R3. This
would result in blackholing of the traffic. 

http://tools.ietf.org/html/rfc5036#section-2.7
	
2.7. LDP Identifiers and Next Hop Addresses
//
   forwarding.  To retrieve the label, the LSR must be able to map the
   next hop address for the prefix to an LDP Identifier.
 .... 
   To enable LSRs to map between a peer LDP Identifier and the peer's
   addresses, LSRs advertise their addresses using LDP Address and
   Withdraw Address messages.
//

Cheers,
Rajiv

> From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-
> lucent.com]
> Sent: Monday, April 02, 2012 11:20 PM
> To: Rajiv Asati (rajiva)
> Cc: [email-masked]; Shah, Himanshu
draft-ietf-
> mpls-ldp-ipv6-06)
> 
> Hi Rajiv,
> Could you provide in details how you believe the presence of duplicate
link-
> local addresses from two neighbouring LSRs can cause blackhole of
traffic?
> 
> What you describe in Section 8 is already how implementations of RFC
5036
> operate. Before you can resolve a FEC to a link, you have to find out
the
> outgoing interface and next-hop of that FEC prefix in the routing
table. Then
> you need to find the LSR-id which advertised that next-hop address as
its local
> address and that there is a hello adjacency to that LSR-id over that
interface. In
> the case of a dual-stack inteface, you just need to find a link Hello
adjacency
> over that interface, it does not have to be an IPv6 adjacency, to
resolve an IPv6
> FEC.
> 
> Because LDP follows routing, you cannot blackhole traffic when
overalpping
> link-local addresses exist to different LDP peers over two different
interfaces or
> subnets. If overlapping occurs over the same subnet, then neighbour
discovery
> will detect it and will shutdown IPv6 forwarding over that interface.
> 
> Again, there is no relationship of FEC resolution to a link and the
type of the
> control plane adjacency. You just need to have an adjacency.
> 
> Regards,
> Mustapha.
> 
draft-ietf-
> IPv6 hello & IPv4 hello and maintaining hello adj for both on a
dual-stack
> interface if enabled with both LDP IPv4 and LDP IPv6:
> 
for
> bootstrapping the subsequent TCP session (and resorting to using the
alternate
> transport if the preferred one failed)
collision)!
> 
> 2. Resolving the label correctly even if duplicate IPv6 LLAs are used
as the
> routing next-hops
> While it may be tempting to maintain only one hello adj (IPv4, say)
(that got
> used to establish the subsequent (IPv4, say) TCP/LDP session) and let
go of the
> other hello adj (IPv6, say) that didn't get used, it could cause
traffic blackholing
> (due to missing #2 above) for packets going on LSPv6.
> 
> Does this clarify?
> 
> Cheers,
> Rajiv
> 
>

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 6 Apr 2012 13:12:49 -0500

Hi Rajiv,
FEC resolution relies on the correct routing information. LDP cannot figure it out by itself. In the same setup below, routing provides the reachability for FEC prefixes x and y with both outgoing interface and next-hop. LDP has to use both information and there will be no balckholing of traffic as I explained below.

In fact, FEC prefix x can be reachable over both interfaces R2-R3 and R2-R5 in the case of equal-cost multipath and LDP on R2 must be able to use both interfaces to forward packets for this FEC. It needs to find the label to use over each interface by checking which LDP identifiers {LSR-id, label-space-id} advertised the next-hop address and that there is a hello-adjacency over each the outgoing interface for a gvien {LSR-id, label-space-id}.

There is no need to maintain two link Hello adjacencies over the same interface for resolving an IPv4 or an IPv6 FEC. I hope we can agree to this by now.

We just published a draft to specify LDP adjacency capability negotiation. This is the correct way to control which FECs can be resolved to a link such that we can keep IPv6 and IPv4 FEC resolution compatibe with RFC 5036 in the case of dual-stack interfaces:
http://www.ietf.org/id/draft-pdutta-mpls-ldp-adj-capability-00.txt

Please let me know if you have any comments.

Mustapha.
-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:[email-masked]]
Sent: Thursday, April 05, 2012 3:46 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: [email-masked]; Shah, Himanshu
Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06)

Hi Mustapha,

Please see inline,

link-
traffic?

R1--R2----R3---R4----"x"
        \-----R5-----------"y"

Relying on just RFC5036 section 2.7 that describes the next-hop/label resolution using ADDRESS message and says nothing about Hello Adjacency,
R2 may map LLAx to R5 and use R5's label while forwarding to R3. This would result in blackholing of the traffic.

2.7. LDP Identifiers and Next Hop Addresses //

Cheers,
Rajiv

draft-ietf-
link-
traffic?
5036
the
table. Then
its local
interface. In
adjacency
resolve an IPv6
overalpping
interfaces or
discovery
type of the
draft-ietf-
dual-stack
for
alternate
collision)!
as the
(that got
go of the
traffic blackholing