Mustapha,
It will fall to me to try to draw some form of consensus out of this discussion
so I have would like to clarify some things.
Are you reporting an interop problem with widely deployed implementations, or an
interop problem with one release of one implementation? The latter is what I
would call a bug, since the problem is a failure to conform to 5036. The former
is, of course, a bigger problem.
Are you reporting a problem that is exclusive to multi-access links? While this
is an important use case, it is a little marginal.
In short, do you have a corner case comprising of:
- multi-access link
- combined legacy v4 nodes and new v6 nodes
- a non-conformant v4 node
...or is the problem larger than that?
Thanks,
Adrian
-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Aissaoui,
Mustapha
(Mustapha)
Sent: 19 December 2014 14:14
To: mark(_dot_)tinka(_at_)seacom(_dot_)mu
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to
LDP for
IPv6) to Proposed Standard
Hi Mark,
Indeed the reason I raised the issue in the summer was to make sure we do not
disrupt existing LDPv4 deployments and that we do not need to upgrade a LDPv4
node which does not comply to this LDPv6 spec. So, both proposed methods put
the onus on the LDPv6 compliant node to automatically detect a router which is
not compliant to LDPv6 such that it will not send to that node LDP IPv6 FECs
and
IPv6 addresses.
From that perspective, the draft now addressed the issue. My latest message
was raising concerns about the specific method added to the draft and by which
the LDPv6 compliant LSR goes about addressing the issue.
I hope this clarifies the situation.
Regards,
Mustapha.
-----Original Message-----
From: Mark Tinka [mailto:mark(_dot_)tinka(_at_)seacom(_dot_)mu]
Sent: Friday, December 19, 2014 7:25 AM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to
LDP
for
IPv6) to Proposed Standard
On Friday, December 19, 2014 01:25:15 AM Aissaoui, Mustapha
(Mustapha) wrote:
What we were debating is if we should use the LDP capability TLV
mechanism which LDP uses to advertise any new capability not supported
by previous implementations versus overloading another TLV which was
not meant for capability discovery.
As an operator, having to upgrade a non-compliant device that is not yet
ready
to
run LDPv6 so that a neighboring LDPv6-capable device planning to run LDPv6
can
still form
LDPv4 adjacencies is quite heavy-handed.
Upgrading a device for anything LDPv6 should, ideally, be in the interest of
getting
LDPv6 deployed, and not to prevent
LDPv4 adjacency tear-down due to capability incompatibility.
On the other hand, it might be worthwhile looking into adding a knob for an
LDPv6-
compliant device to tell it to have backwards compatibility with
non-compliant
devices on the wire. Since one would, in all likelihood, be upgrading a non-
compliant
device to make it compliant, the heavy-hand makes sense here since an
operator
needs to get the code in anyway.
Mark.
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls