Subject: [CCAMP] Resolutions of comments on draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext

From: Lou Berger <[email-masked]>
Date: Thu, 01 Nov 2012 17:28:14 -0400

Authors,
	Can you state how the comments in the following messages have been
addressed in the latest version?

http://www.ietf.org/mail-archive/web/ccamp/current/msg13559.html

http://www.ietf.org/mail-archive/web/ccamp/current/msg13837.html

I also note that no updated version was posted based on the thread
completed in:
http://www.ietf.org/mail-archive/web/ccamp/current/msg14063.html.

Please let us know if you have any open issues you'd like to discuss in
next week's sessions.  We have a couple of cancellations and can fit you
in, if needed.  (And closing on the open issues will help unblock these
documents.)

Much thanks,
Lou

---

From: Pontus Sköldström <[email-masked]>
Date: Mon, 26 Nov 2012 16:24:09 +0100

Hi everyone, 

I've resolved all the comments except one, and would like to ask if anyone has some good advice regarding that one. 

The problem was pointed out by Fei Zhang in http://www.ietf.org/mail-archive/web/ccamp/current/msg13559.html
  "Line 368,  As discussed in the mailinglist when polling the draft 
            http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03, the tunnel number assigned by the egress 
           LER should be carried back. This issue can be addressed here or in that or other document, but I am afraid the current description 
           needs to be changed.  "

The problem is that both MEPs needs to know what values in the MEP-ID field of the encapsulated BFD control packet they should expect from the other endpoint, so the full MEP-ID of the other side of the connection is needed. 
As far as I can see there are two options:

1. Extend the current "Local discriminator" TLV (http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-10#section-3.3.1) to include the full MEP-ID. 
The Path message carries the ingress MEP-ID it to the egress, and the egress replaces it with its own MEP-ID in the Resv message. 

2. Use the mechanism described in http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-05 to carry the Tunnel_Num of the egress back to the ingress. 
With this value (carried in the ASSOCIATION object) available, both sides can derive what the other sides MEP-ID should be. 

I propose solution #1, since it puts all the information needed for configuration in one neat group, and not spread out over multiple RSVP object. 
Personally I think solution #2 is bit clumsy since you, as an implementer, have to gather information from a bunch of different objects to construct the final MEP-ID. 

Any comments? 

Best regards, 

Pontus Sköldström, M.Sc.
Research Scientist
Netlab - Networking and Transmission Laboratory
+46 8 632 7731
[email-masked]

Acreo AB – Part of Swedish ICT
Electrum 236, 164 40 Kista, Sweden
www.acreo.se
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lou Berger [[email-masked]]
Sent: Thursday, November 01, 2012 22:28
To: [email-masked]
Cc: CCAMP
Subject: [CCAMP] Resolutions of comments on     draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext

Authors,

Much thanks,
Lou
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp