The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Hi JL,

Sorry for the delay. Please see below:

On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi all,
>
> I transfer the below comments on this list,
> as it should be discussed as part of last call comments.
>
> Regards,
>
> JL
>
> > -----Message d'origine-----
> > De : LE ROUX Jean-Louis RD-CORE-LAN
> > Envoyé : jeudi 25 mai 2006 14:19
> > À:
> > Objet : RE: working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> > Hi Rahul, Dimitri, Seisho
> >
> > Thanks for the great edit job,
> >
> > Find below a set of comments on this revision 05
> >
> > Four technical points:
> >
> > 1: Section 8.1.2 Downstream notification
> >
> > The text in 8.1.2 is a bit unclear
> >
> > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> >    object(s) of a Resv message to the value, that was received in the
> >    corresponding Path message. If the incoming Resv message carries a
> >    Notify Request object then, the LSR MUST set the Notify
> > node address
> >    in the Notify Request object to the value, that was received in the
> >    corresponding Path message",
> >


> > Which value? The sub-group originator? the notify address?

This should be the Router ID of the transit LSR if the transit LSR is
merging more than one Resv with a Notify Request object.

> > This is unclear.  The processing needs to be clarified.
> > We could update as follows:
> >
> > "If the incoming Resv message carries a Notify Request object then,
> > 		-If the sub-group originator ID is its own
> > address, the LSR MUST set the Notify node address in the
> > Notify Request object to its own address, in the Resv message
> > that it sends upstream.
> > 	    -If the sub group originator ID is not its own
> > address, the LSR MUST propagate the Notify Request object
> > unchanged, in the Resv message that it sends upstream."
> >

Shouldn't the transit LSR always set its own address in the Notify Request
if it is merging multiple Resvs with Notify Request objects into a single
Resv ? The current text is not clear on this either.

How about:

"A transit LSR sets the Sub-Group Originator ID in the
FILTER_SPEC object(s) of a Resv message to the value, that was received in
the corresponding Path message. If the incoming Resv message carries a
Notify Request object then:

 - If there is at least another incoming Resv message that carries a
Notify Request object and the LSR merges these Resv messages into a single
Resv message that is sent upstream, the LSR MUST set the Notify
node address in the Notify Request object to its Router ID.

- Else the LSR MUST propagate the Notify Request object
unchanged, in the Resv message that it sends upstream."


> > 2: Section 8.2 ResvConf
> >
> > Similar comment
> >
> > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> >    object(s) of a Resv message to the value, that was received in the
> >    corresponding Path message. If any of the incoming Resv messages
> >    corresponding to a single Path message carry a RESV_CONFIRM object
> >    then the LSR MUST include a RESV_CONFIRM object in the
> > corresponding
> >    Resv message that it sends upstream and MUST set the
> > receiver address
> >    in the RESV_CONFIRM object to the value that was received in the
> >    corresponding Resv message."
> >
> > Change to
> >
> > "
> >    A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> >    object(s) of a Resv message to the value, that was received in the
> >    corresponding Path message. If any of the incoming Resv messages
> >    corresponding to a single Path message carry a RESV_CONFIRM object
> >    then the LSR MUST include a RESV_CONFIRM object in the
> > corresponding
> >    Resv message that it sends upstream. If the sub-group
> > originator ID is its own address then
> >    it MUST set the receiver address in the RESV_CONFIRM
> > object to this addresse, else it MUST
> >    propagate the object unchanged"
> >

Shouldn't the transit LSR always set its own address in the RESV_CONFIRM
if it is merging multiple Resvs with RESV_CONFIRM objects into a single
Resv ? The current text is not clear on this either.

How about:

"A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
object(s) of a Resv message to the value that was received in the
corresponding Path message. If an incoming Resv message
corresponding to a single Path message carries a RESV_CONFIRM object
then the LSR MUST include a RESV_CONFIRM object in the corresponding
Resv message that it sends upstream and:

 - If there is at least another incoming Resv message that carries a
RESV_CONFIRM object and the LSR merges these Resv messages into a single
Resv message that is sent upstream, the LSR MUST set the receiver
address in the RESV_CONFIRM object to its Router ID.

- Else the LSR MUST propagate the RESV_CONFIRM object
unchanged, in the Resv message that it sends upstream."



> >
> > 3: Section 14.2 Sub-group based reoptimization
> >
> > The new path may intersect the old path, this is a case of
> > rerouting and this is not covered by remerge procedures as
> > described in section 18. Hence Transient Data duplication may
> > occur during the time between the Resv is received and the
> > PathTear is sent. To avoid data duplication the branch node
> > must not start transmitting on the new path before the old
> > path has been torn down, but this will lead to transient packet loss.
> > This should be clearly mentionned here IMO.
> > Actually the only way to avoid both transient duplication and
> > transient packet loss is to rely on the global mb4b procedure
> > with a new LSP id...
> >

How about adding the following to this section:

"Sub-Group based re-optimization may result in transient data duplication
as the new Path messages for a set of S2L sub-LSPs may transit one or more
nodes with the old Path state for the same set of S2L sub-LSPs. "


> > 4: Section 18.1.1 Remerge Procedure
> >
> > The text says
> >    "The PathErr message MUST include all of the objects
> >    normally included in a PathErr message, as well as one or more SUB-
> >    LSP objects from the set of sub-LSPs associated with the matching
> >    P2MP LSP Path state.  A minimum of three SUB-LSP objects is
> >    RECOMMENDED. This will allow the node that caused the re-merge to
> >    identify the outgoing Path state associated with the valid
> > portion of
> >    the P2MP LSP. The set of SUB-LSP objects in the received
> > Path message
> >    MUST also be included"
> >
> > And then:
> >
> >    "A node that receives a PathErr message that contains the
> > Error Value
> >    "Routing Problem/P2MP Remerge Detected" MUST determine if it is the
> >    node that created the re-merge case.  This is done by checking
> >    whether there is any intersection between the set of
> > SUB-LSP objects
> >    associated with the matching P2MP LSP Path state and the
> > set of SUB-
> >    LSP objects in the received PathErr message.  If there is, then the
> >    node created the re-merge case."
> >
> > There is an issue here. Actually there will always be an
> > intersection, because the PathErr includes the set of sub-lsp
> > objects in the received Path... IMO for this procedure to work
> > the PathErr MUST only include sub-LSP objects associated with
> > the matching P2MP LSP state on the rermerge LSR and must not
> > include the set of SUB-LSP objects in the received Path message.
> > By the way why are three objects recommended?
> >

I believe this was clarified by John Drake offline and no revisions were
needed ?

> >
> > Also find below some minor edits:
> >
> > Section 6.1
> >
> > <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP&>; [ <P2MP
> >    SECONDARY_EXPLICIT_ROUTE> ]
> > Change to:
> > <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP&>; [ <P2MP
> >    SECONDARY_RECORD_ROUTE> ]
> >

Ok.

> > Section 7.1
> > <S2L sub-LSP list> change to <S2L sub-LSP descriptor list>
> >

Ok.

> > Section 8.1.2
> >
> >  "If this LSR subsequently receives a corresponding Notify
> > message from
> >    an upstream LSR than it MUST:
> >    - send a Notify message downstream toward the Notify
> >      node address that the LSR received in the Resv message.
> >    - process the sub-group fields of the FILTER_SPEC object in the
> >      received Notify message, and modify their values in the Notify
> >      message that is forwarded to match the sub-group field values
> >      in the original Path message sent downstream by this LSR."
> >
> > Invert these two bullets
> >

Ok.

> > Section 8.2
> >
> > "If this LSR subsequently receives a corresponding ResvConf message
> >    from an upstream LSR then it MUST:
> >    - send a ResvConf message downstream toward the receiver
> > address that
> >      the LSR received in the RESV_CONFIRM object in the Resv message.
> >    - process the sub-group fields of the FILTER_SPEC object in the
> >      received ResvConf message, and modify their values in
> > the ResvConf
> >      message that is forwarded to match the sub-group field values
> >      in the original Path message sent downstream by this LSR."
> >
> > Invert these two bullets
> >

Ok.

> > Section 11.2 last sentence
> >
> >    "Note the receiver of a ResvErr message is able to
> > identify the errored outgoing Path [Change to: Resv]
> >    message, and outgoing interface, based on the Sub-Group fields
> >    received in the ResvErr message.
>

Ok.

>
> > Section 13
> >
> >  "A sender on a LAN uses a different label for sending traffic to each
> >    node on the LAN that belongs to the P2MP LSP"
> >
> > This is not always the case, I would rather say
> >
> > "Downstream nodes for a given P2MP LSP on a LAN are likely to
> > allocate a different label, in which case the sender has to
> > perform replication"...
> >

Actually the procedures in this document imply that a sender on a LAN must
do replication if there is more than one downstream receiver. Upstream
labels are required to avoid this.

However I do realize that the first sentence is not entirely accurate. How
about:

"If there are multiple downstream LSRs on a LAN on a P2MP LSP, a sender
LSR on the LAN has to perform replication. A separate copy of the data
is unicast to each of the downstream LSRs"


> > Section 16
> >
> >    "Stitching and nesting
> >    considerations and procedures are described further in [INT-REG]."
> >
> > Change to "Stitching and nesting
> >    considerations and procedures are described further in
> > [LSP-STITCH] and [RFC4206]."
> >
> > Section 17
> >
> > Infact => In fact
> >

Ok.

> > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object => P2MP
> > LSP_IPv6 FILTER_SPEC object
> >

Ok.

> > Also some references need to be updated...
> >

Will do that.

Thanks for the detailed comments.

rahul

> > Best Regards,
> >
> > JL
> >
> > > -----Message d'origine-----
> > > De : owner-ccamp@ops.ietf.org
> > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa
> > Andersson Envoyé :
> > > samedi 13 mai 2006 12:48 À : mpls@ietf.org Cc : ccamp;
> > George Swallow;
> > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross Callon; Bill Fenner
> > > Objet : working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> > >
> > > Working Group,
> > >
> > > this initiates a two week working group last call on
> > > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> > >
> > > please send comments to the MPLS working group mailling list and/or
> > > working co-chairs.
> > >
> > > The last call ends eob May 28th.
> > >
> > > The ccamp mailing list copied as this is a work that has an overlap
> > > between the working groups.
> > >
> > > Loa and George
> > >
> > >
> > >
> > > --
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  loa.andersson@acreo.se
> > >                                            loa@pi.se
> > >
> > >
>
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
>
>

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls