[bess] Comments on draft-ietf-bess-ir

[<[e-mail]>]

Hi everyone,



> 1. Introduction
[...]
> This document does not provide any new protocol elements or 
> procedures; [...]

Sections 3, 4.1.1 and 9, at least, introduce what I think can fairly be 
considered new procedures.
(The fact that the document introduces new procedures is fine I think, 
and not inconsistent with the fact that it updates past RFCs.)

>
> 2.  What is an IR P-tunnel?
[...]
>      Typically the unicast tunnels are the Label Switched Paths (LSPs)
>    that already exist to carry unicast traffic; either MP2P LSPs created
>    by LDP [RFC5036] or P2P LSPs created by RSVP-TE [RFC3209]. However,
>    any other kind of unicast tunnel may be used.

> 4.1. Advertised P-tunnels
> The procedures in this section apply when the P-tunnel to be joined 
> has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D 
> route, or an Intra-AS I-PMSI A-D route.
>

For sake of clarity and avoid any misinterpretation, can you please add 
", and the PMSI Tunnel Attribute is of type Ingress Replication" since 
these procedures of course do not apply to any other tunnel type.


[...]
> 4.1.2.  If the 'Leaf Info Required Bit' is Not Set
>
[...]
>
>    Note that if a set of IR P-tunnels is joined in this manner, the
>    "discard from the wrong PE" procedures of [RFC6513] section 9.1.1
>    cannot be applied to that P-tunnel.  Thus duplicate prevention on
>    such IR P-tunnels requires the use of either Single Forwarder
>    Selection ([RFC6513] section 9.1.2) or native PIM procedures
>    ([RFC6513] section 9.1.3).

I would suggest rewording with "Note that, in the general case, ..." and 
"...unless the tunneling technique relies on an IP transport, which may 
allow the identification of the PE sourcing the traffic".

> 9.  Use of Timers when Switching UMH
>
>    Suppose a child node has joined a particular IR P-tunnel via a
>    particular UMH, and it now determines (for whatever reason) that it
>    needs to change its UMH on that P-tunnel.  It does this by modifying
>    the RT of a Leaf A-D route.
[...]
> However, the control plane operation
>    (modifying the RT of the Leaf A-D route) does not permit the child
>    node to first join the P-tunnel at the new UMH, and then later prune
>    itself from the old UMH

As I read the above, I understand --even if that is a bit implicit-- 
that the NLRI for the Leaf A-D route to the old UMH is the same as the 
NLRI for the Leaf A-D route to the new UMH.

But I don't in fact understand why this has to be the case...

[[ One has to ignore the procedures to build a Leaf A-D route of RFC6514 
since this document specifies new ones for IR in section 4.1.1 -- but it 
would help to say upfront that "the section applies in the context of 
the procedures in section 4.1.1" (an uncautious reader re-reading 
section 9 without having re-read section 4.1 may be lost -- of course, 
this is pure fiction, and it could certainly not have happened to me...) ]]

Now, let me go back to section 4.1.1 and section 3:
- section 4.1.1 says that the Key field of the Leaf A-D route contains 
the "tunnel identifier" defined in section 3
- section 3 says that (when the "Leaf info required" bit is set, which 
is the case for section 4.1.1) the tunnel identifier is RECOMMENDED to 
be a routable address of the router that built the PTA

Why not make it MANDATORY to use put an address specific to the router 
that built the PTA in the tunnel identifier and thus ensure that the 
Leaf A-D route to the old UMH will be different than Leaf A-D route to 
the new UMH ?

(I understand that maybe there is a difficulty that there might be 
contexts where the router that built the PTA is not the UMH, but I fail 
to identify a context where it would be the case and IR would be used -- 
if the motivation for this choice of procedure lies in this specific 
aspect that would really deserve to be exposed, documented and possibly 
debated)

Anyhow, it seems to me that ensuring that the Key changes when the UMH 
changes, would simplify the make before break procedure: everything is 
at the hand of the downstream PE which can advertise both routes for as 
long as it wishes, without introducing any issues related to the 
consistent configuration of the timers in 1 (upstream PE) and 2 
(downstream PE)  -- as we know well, having to add tuning knobs has a 
direct implementation/test/OSS cost and having to configure two things 
consistently in two different places is a recipe for failure.

-Thomas


_________________________________________________________________________________________________________________________

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.