Re: Comments on draft-ietf-mpls-ldp-ipv6-06

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: 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
 //

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

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

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

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

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

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

Cheers,
Rajiv

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

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

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

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

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

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

Mark.

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

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
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls