Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03

Hi Bruno,
Thanks for the response. Please see inline...

On Fri, Jun 2, 2017 at 3:12 AM, <bruno.decraene@orange.com> wrote:

> Dear Shyam,
>
>
>
> Thanks for the review and feedback
>
> Please see inline [Bruno]
>
>
>
> *From:* Shyam Sethuram [mailto:shyam.ioml@gmail.com]
> *Sent:* Friday, June 02, 2017 12:43 AM
> *To:* John G. Scudder
> *Cc:* idr@ietf. org; mpls@ietf.org; draft-decraene-idr-next-hop-
> capability@bgp.nu
> *Subject:* Re: [mpls] Working Group adoption call for
> draft-decraene-idr-next-hop-capability-03
>
>
>
> Dear authors,
>
>
> Some of the language sounds similar to that in
> draft-ietf-idr-tunnel-encaps.
> Did you consider augmenting tunnel-encaps in order to signal EL by
> adding a new sub-TLV ? It is a transitive attribute but it has a
> Remote Endpoint sub-TLV to bind the capability to the specific nexthop.
> (It may require a new "tunnel type" to represent plain MPLS nexthops.)
>
> [Bruno] To be honest, we have not considered using
> draft-ietf-idr-tunnel-encaps. That being said, if it’s a transitive
> attribute, it seems like a no go as this is the reason why the original ELC
> BGP attribute had been deprecated: cf this short section
> https://tools.ietf.org/html/rfc7447#section-1
>
>
>

Yes any transitive attribute would have this issue. The tunnel-encaps
solves this by encoding the nexthop address also in the Remote Endpoint
sub-TLV. The receiver can then compare that with the MP_REACH nexthop
and perform required validations.

At a high level, I wanted to see if there was a way to avoid
having two separate attributes that both essentially deal with nexthops.
It is quite possible that a speaker receives both nexthop-cap and
tunnel-encaps
attributes for that same nexthop and has to synthesize the two data before
installing into forwarding. On the other hand, tunnel-encaps has turned
into a
"monster attribute" with the whole kitchen sink in it; I can see a fertile
breeding ground for implementation bugs :-)
So I guess we'll see if anyone else has any opinion on this.

Coming back to your attribute, as I said earlier w.r.t. coloring, I know
atleast one usecase that wants to apply EL only to particular
types of overlay traffic (for example, L2 vs L3 VPN) recursing to
a given nexthop with EL capability. There are many ways to
address that - a config knob, signal within the NH attribute, use the
color extcomm and so on. If you have any thoughts on the same,
please add it to the draft.

> This would avoid the need to upgrade all the BGP speakers between egress
> and ingress. tunnel-encaps also has a Color sub-TLV that can be useful,
> for example, when using recursive resoltion, to select a subset of overlay
> prefixes that would actually use EL for forwarding.
>
>
>
> That said, some nitpicks:
> - dependant==>dependent;
>
> [Bruno] Thanks
>
> infact it can be totally avoided and just call it "Nexthop capabilites"
>
> [Bruno] Yes and that was the initial text. However, this had generated
> some misunderstanding. In particular because the attribute is not
> advertising the capability of the Next-Hop, but capability of this Next-Hop
> _for the routes advertised with this capability. In particular, one
> Next-Hop may advertise different capabilities for different routes. This is
> in needed for the Entropy Label Capability, as this ELC is FEC specific.
>
> That being said, I’m not that happy with the wording “Next-Hop dependent
> capability”, hence any other suggestion is welcomed.
>
>
> - that said, it would be better to avoid reusing the term "Capabilities"
> for this
> attribute though I understand you are trying to draw a parallel with
> session capabilities
>
> [Bruno] Indeed, I was trying to draw a parallel with session capability.
> Could you elaborate on why the term “Capabilities” is not optimal? Would
> you have alternate suggestion?
>

I don't have a strong opinion on this, it just seemed odd to reuse
terminology from the base spec for a different purpose. I guess we can call
it
nexthop-properties or nexthop-forwarding-info or some such thing. No big
deal,
it's just a nit.

thanks--shyam

>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> thanks--shyam
>
>
>
> On Thu, May 18, 2017 at 9:32 AM, John G. Scudder <jgs@juniper.net> wrote:
>
> Hi All,
>
> IDR working group adoption has been requested for
> draft-decraene-idr-next-hop-capability-03. Please send your comments to
> the IDR mailing list before June 2, 2017. Please remember that we need
> affirmative support in order to adopt the draft, so don't be shy.
>
> draft datatracker page: https://datatracker.ietf.org/
> doc/draft-decraene-idr-next-hop-capability/
> slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-
> 98-idr-08-bgp-next-hop-dependent-capabilities-00.pdf
>
> Since in part this draft specifies a replacement for the Entropy Label
> Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and
> deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the
> proposed new attribute is a generic container with the ELCA replacement
> just the first application, the current draft is targeted to IDR and not
> MPLS (this was discussed during IETF-93).
>
> Thanks,
>
> --John
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>